tools
ts-sql
tools | ts-sql | |
---|---|---|
45 | 28 | |
24,334 | 3,114 | |
- | 0.0% | |
0.0 | 0.0 | |
8 months ago | almost 3 years ago | |
Rust | TypeScript | |
MIT License | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
tools
-
Biome.js : Prettier+ESLint killer ?
Biome is a fork of Rome, which was originally an ambitious tool written in Rust but abandoned in October 2023. It includes both a linter and a formatter, putting an end to the time-consuming difficulties associated with reconciling ESLint and Prettier rules.
-
Rescuing legacy Node.js projects with Bun
When I saw the release of bun six months ago, I was not that hyped as I saw a tool that had similar ambitions, Rome, and dissapointed many. But it was different this time. It really is a drop in replacement for Node.js so you can start using it by replacing the npm and node commands in your package.json file. The main feature that captured my interest was the ability to use require and import statemtents in the same file. This allows you to keep using CommonJS modules and use import statemtents for any new modules that drop support for it. The only catch I could find so far is that if you decide to mix import and require statements, you cannot use module.exports but instead use export statement. I did exactly that and now I have a fully functional backend with admin panel that won't make your head scratch fighting with CommonJS and ESModules.
-
Build a Vite 5 backend integration with Flask
Once you build a simple Vite backend integration, try not to complicate Vite's configuration unless you absolutely must. Vite has become one of the most popular bundlers in the frontend space, but it wasn't the first and it certainly won't be the last. In my 7 years of building for the web, I've used Grunt, Gulp, Webpack, esbuild, and Parcel. Snowpack and Rome came-and-went before I ever had a chance to try them. Bun is vying for the spot of The New Hotness in bundling, Rome has been forked into Biome, and Vercel is building a Rust-based Webpack alternative.
-
BiomeJS 2024 Roadmap
It definitely existed by the time rome_console/biome_console was created! The crate was created 2 years ago[1] and miette was released more than 2 years ago[2]. By the time rome_console was created miette was on v4, so presumably somewhat mature.
[1]: https://github.com/rome/tools/commits/main/crates/rome_conso...
[2]: https://crates.io/crates/miette/versions
-
Biome
Biome formats and lints your JavaScript and TypeScript code in a fraction of a second. Biome is the community successor of Rome Tools [0].
As part of this announcement, we have released the first stable version of Biome [1]. Join us on our Discord [2] and support us via our open collective [3].
I am one of the main maintainers of Biome. I will be happy to answer any questions :)
[0] https://github.com/rome/tools
-
JavaScript Gom Jabbar
I have no idea how true this is, but the source of the claim seems to come from here:
https://github.com/rome/tools/discussions/4302
"But in short, the company Rome Tools ran out of funding, so the core team of last year are no longer working on the project."
-
Rome v12.1: a Rust-based linter formatter for TypeScript, JSX and JSON
For now, Rome implements most of the ESLint recommended rules (including TypeScript ESLint) and some additional rules that are enabled by default. In the future, you can expect a recommended preset that is a superset of the ESLint recommended preset. So if you're not heavily customising ESLint, you should be able to use Rome.
Otherwise, most of the rules are not fine-tunable in the way that ESLint is. Rome tries to provide the experience that Prettier provided in the formatting tool: good defaults for a near-zero configuration experience. It tries to adopt the conventions of the JS/TS community. Still, some configuration is provided when the community is divided on some opinions (e.g. space vs. tab indentation, semicolons or as-needed semicolons, ...).
There is an open issue [1] for listing equivalent rules between ESLint and Rome. Expect more documentation in the future, and maybe a migration tool.
If I had been one of the founders of Rome, I could have pushed for more compatibility with ESLint. In particular, using the same naming conventions and thus the same names for most rules, and recognising ESLint ignore comments.
[1] https://github.com/rome/tools/issues/3892
-
Rome
Today we are going to talk about Rome. According to their github page
-
Complete rewrite of ESLint (GitHub discussion by the creator)
I must say, although it doesn't (of course) have anywhere near the configuration or plugin-capability of eslint, I've found Rome impressive so far. I have access to a range of PCs and the performance boost of a compiled binary makes a pretty big difference on a large repo on a slower machine.
-
Porting 58000 lines of D and C++ to jai, Part 0: Why and How
Fast compilation seems very appealing. It is one of the main reason why I am interested into Go and Zig.
I recently started working with Rust for contributing to projects like Rome/tools [1] and deno_lint [2]. The compilation and IDE experience is frustrating. Compilation is slow. I am afraid that this is rooted to the inherent complexity of Rust.
[1] https://github.com/rome/tools
[2] https://github.com/denoland/deno_lint
ts-sql
-
Type-Safe Printf() in TypeScript
There is an implementation of SQL that operates on a table shaped type, entirely at type level. For your amusement: https://github.com/codemix/ts-sql
There are a bunch of more practical takes that codegen types from your database and generate types for your queries, eg: https://github.com/adelsz/pgtyped
To me the second approach seems much more pragmatic because you don’t need to run a SQL parser in a fairly potato interpreter on every build
- Functions and algorithms implemented purely with TypeScript's type system
- Que opinan de esta forma de actualizar estados complejos en React, creen que es buena practica o tienen una mejor forma?
-
How to Sell Elixir Again (2023)
> If I would level criticisms at dialyzer it would be its sometimes difficult to read warnings, it’s speed (despite being multithreaded) and the race conditions in the VS Code plugin (which is looking for extra maintainers – if I had time I would help).
One of the advantages of TypeScript is that VSCode is written in TypeScript, and both VSCode and TypeScript are developed by the same company, so there's a really nice synergy there. I imagine Kotlin users feel the same way using Jetbrains products, and Swift users feel the same way about XCode.
Dialyzer looks interesting, but I can't imagine giving up on the expressiveness of TypeScript. Some of the things you can do with generics, mapped types, intersection types, template literal types, conditional types, and utility types are almost mind boggling. It's difficult to reap all of the benefits of static analysis without some of these advanced type operators. The type manipulation section of the TS manual is really underrated.
Someone for example wrote an SQL parser in TypeScript that requires no runtime code [1]. It can infer the types of an SQL query's result based on an SQL string without any runtime code execution. There was a similar project where someone built a JSON parser entirely using the type system [2]. There's also an ongoing discussion on Github about the the fact that TypeScript's type system appears to be a Turing-complete language with some other cool examples [3]. My point is that the type system is incredibly expressive. You rarely run into an idiom that can't be typed effectively.
[1] https://github.com/codemix/ts-sql
[2] https://twitter.com/buildsghost/status/1301976526603206657
[3] https://github.com/microsoft/TypeScript/issues/14833
- Please use Typescript
- TypeScripting the Technical Interview
-
Pls can we go back to traditional languages?
If anyone saw this meme and thought, "damn parsing a type from a SQL query, that looks useful" (as I did), the source appears to be from here.
-
Type-Level FizzBuzz
I mean, why stop there? https://github.com/codemix/ts-sql
-
HypeScript: Simplified TypeScript's type system in TypeScript's own type system
Which allows for things like this type that implements a simplified SQL query parser checked against a provided 'database' object:
https://github.com/codemix/ts-sql
This project was my go-to "nifty but pointless" example for TS string literal types before this article :)
-
Deepkit – High-Performance TypeScript Framework
author of ts-sql[0] here, this looks great (and a way more practical approach!)
[0] https://github.com/codemix/ts-sql
What are some alternatives?
biome - A toolchain for web projects, aimed to provide functionalities to maintain them. Biome offers formatter and linter, usable via CLI and LSP.
slonik - A Node.js PostgreSQL client with runtime and build time type safety, and composable SQL.
yarn.build - Build 🛠 and Bundle 📦 your local workspaces. Like Bazel, Buck, Pants and Please but for Yarn Berry. Build any language, mix javascript, typescript, golang and more in one polyglot repo. Ship your bundles to AWS Lambda, Docker, or any nodejs runtime.
Paste JSON as Code • quicktype - Xcode extension to paste JSON as Swift, Objective-C, and more
msgpack-tools - Command-line tools for converting between MessagePack and JSON / msgpack.org[UNIX Shell]
pgtyped - pgTyped - Typesafe SQL in TypeScript
sucrase - Super-fast alternative to Babel for when you can target modern JS runtimes
lean4 - Lean 4 programming language and theorem prover
deno_lint - Blazing fast linter for JavaScript and TypeScript written in Rust
sqlx - 🧰 The Rust SQL Toolkit. An async, pure Rust SQL crate featuring compile-time checked queries without a DSL. Supports PostgreSQL, MySQL, and SQLite.
gcc
kanel - Generate Typescript types from Postgres