Prettier $20k Bounty was Claimed

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • WorkOS - The modern API for authentication & user identity.
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • Onboard AI - ChatGPT with full context of any GitHub repo.
  • biome

    A toolchain for web projects, aimed to provide functionalities to maintain them. Biome offers formatter and linter, usable via CLI and LSP.

    The Biome team has been incredibly fast on solving the challenge and achieving 95% compatibility with Prettier [1]

    Just as a note, as it was not mentioned in the article, Wasmer [2] also participated with a $2,500 bounty to compile Biome to WASIX [3], and it has been awesome to see how their team has been working to achieve this as well... hopefully we'll get Biome running in Wasmer soon!

    Keep up the great work!!

    [1] https://github.com/biomejs/biome/issues/720

    [2] https://wasmer.io/

    [3] https://wasix.org/

  • prettier

    Prettier is an opinionated code formatter.

    Some things overlooked in that blog post for others to take into consideration:

    - eslint only works on javascript + typescript (eslint + typescript needs _more_ configuration than eslint + prettier), while prettier works on https://github.com/prettier/prettier/blob/03ebc7869dc9e8f2fc...

    - eslint + prettier doesn't need lots of configuration from the user. You add eslint-plugin-prettier and say `"extends": ["plugin:prettier/recommended"]`

  • WorkOS

    The modern API for authentication & user identity. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  • wasmer

    🚀 The leading Wasm Runtime supporting WASIX, WASI and Emscripten

    The Biome team has been incredibly fast on solving the challenge and achieving 95% compatibility with Prettier [1]

    Just as a note, as it was not mentioned in the article, Wasmer [2] also participated with a $2,500 bounty to compile Biome to WASIX [3], and it has been awesome to see how their team has been working to achieve this as well... hopefully we'll get Biome running in Wasmer soon!

    Keep up the great work!!

    [1] https://github.com/biomejs/biome/issues/720

    [2] https://wasmer.io/

    [3] https://wasix.org/

  • prettier-plugin-curly

    Prettier plugin to enforce consistent brace style for all control statements. 🥌

  • awesome-eslint

    A list of awesome ESLint plugins, configs, etc.

  • TypeScript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

    You can already mostly do this with dprint's TypeScript plugin if you tweak the config (and I'm open to adding more config to support this scenario). For example, the TypeScript team uses a line limit of 1000: https://github.com/microsoft/TypeScript/blob/1797837351782e7...

  • jco

    JavaScript tooling for working with WebAssembly Components

    The roadmap I linked above. The WASI folks have done a poor job at communicating, no doubt, but I'm surprised someone like yourself literally building a competitor spec isn't following what they are doing closely.

    Just for you I did some googling: see here[0] for the current status of WASI threads overall, or here[1] and here[2] for what they are up to with WASI in general. In this PR[3] you can see they enabled threads (atomic instructions and shared memory, not thread creation) by default in wasmtime. And in this[4] repository you can see they are actively developing the thread creation API and have it as their #1 priority.

    If folks want to use WASIX as a quick and dirty hack to compile existing programs, then by all means, have at it! I can see that being a technical win. Just know that your WASIX program isn't going to run natively in wasmtime (arguably the best WASM runtime today), nor will it run in browsers, because they're not going to expose WASIX - they're going to go with the standards instead. so far you're the only person I've met that thinks exposing POSIX fork() to WASM is a good idea, seemingly because it just lets you build existing apps 'without modification'.

    Comical you accuse me of being polarizing, while pushing for your world with two competing WASI standards, two competing thread creation APIs, and a split WASM ecosystem overall.

    [0] https://github.com/bytecodealliance/jco/issues/247#issuecomm...

    [1] https://bytecodealliance.org/articles/wasmtime-and-cranelift...

    [2] https://bytecodealliance.org/articles/webassembly-the-update...

    [3] https://github.com/bytecodealliance/wasmtime/pull/7285

    [4] https://github.com/WebAssembly/shared-everything-threads

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  • wasmtime

    A fast and secure runtime for WebAssembly

    The roadmap I linked above. The WASI folks have done a poor job at communicating, no doubt, but I'm surprised someone like yourself literally building a competitor spec isn't following what they are doing closely.

    Just for you I did some googling: see here[0] for the current status of WASI threads overall, or here[1] and here[2] for what they are up to with WASI in general. In this PR[3] you can see they enabled threads (atomic instructions and shared memory, not thread creation) by default in wasmtime. And in this[4] repository you can see they are actively developing the thread creation API and have it as their #1 priority.

    If folks want to use WASIX as a quick and dirty hack to compile existing programs, then by all means, have at it! I can see that being a technical win. Just know that your WASIX program isn't going to run natively in wasmtime (arguably the best WASM runtime today), nor will it run in browsers, because they're not going to expose WASIX - they're going to go with the standards instead. so far you're the only person I've met that thinks exposing POSIX fork() to WASM is a good idea, seemingly because it just lets you build existing apps 'without modification'.

    Comical you accuse me of being polarizing, while pushing for your world with two competing WASI standards, two competing thread creation APIs, and a split WASM ecosystem overall.

    [0] https://github.com/bytecodealliance/jco/issues/247#issuecomm...

    [1] https://bytecodealliance.org/articles/wasmtime-and-cranelift...

    [2] https://bytecodealliance.org/articles/webassembly-the-update...

    [3] https://github.com/bytecodealliance/wasmtime/pull/7285

    [4] https://github.com/WebAssembly/shared-everything-threads

  • shared-everything-threads

    A draft proposal for spawning threads in WebAssembly

    The roadmap I linked above. The WASI folks have done a poor job at communicating, no doubt, but I'm surprised someone like yourself literally building a competitor spec isn't following what they are doing closely.

    Just for you I did some googling: see here[0] for the current status of WASI threads overall, or here[1] and here[2] for what they are up to with WASI in general. In this PR[3] you can see they enabled threads (atomic instructions and shared memory, not thread creation) by default in wasmtime. And in this[4] repository you can see they are actively developing the thread creation API and have it as their #1 priority.

    If folks want to use WASIX as a quick and dirty hack to compile existing programs, then by all means, have at it! I can see that being a technical win. Just know that your WASIX program isn't going to run natively in wasmtime (arguably the best WASM runtime today), nor will it run in browsers, because they're not going to expose WASIX - they're going to go with the standards instead. so far you're the only person I've met that thinks exposing POSIX fork() to WASM is a good idea, seemingly because it just lets you build existing apps 'without modification'.

    Comical you accuse me of being polarizing, while pushing for your world with two competing WASI standards, two competing thread creation APIs, and a split WASM ecosystem overall.

    [0] https://github.com/bytecodealliance/jco/issues/247#issuecomm...

    [1] https://bytecodealliance.org/articles/wasmtime-and-cranelift...

    [2] https://bytecodealliance.org/articles/webassembly-the-update...

    [3] https://github.com/bytecodealliance/wasmtime/pull/7285

    [4] https://github.com/WebAssembly/shared-everything-threads

  • age

    A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability.

    I never heard of "Age" before this post. Thank you to share. If others are interested to learn more, here are two other interesting posts about Age:

    https://github.com/FiloSottile/age/discussions/432

    https://words.filippo.io/dispatches/age-authentication/

  • prettier-rpc

    Discontinued Single-file build of prettier with JSON-RPC communication

    Sorry for being late to the party. What I really care about is that we have fast code formatting in the industry.

    But performance is a field that's really hard to accurately measure as there are so many variables, machines, benchmarks... You can see this in the JavaScript ecosystem where every project says that they are faster than the other one and they are in practice all right depending on which benchmarks they use.

    So, creating a big bounty with something that's very hard to accurately measure is likely not going to work out very well.

    In practice in the ecosystem, the Rust community really cares about performance. So it feels that this is the right audience to build something really fast. But, so far, none of the Rust-based printers were even close to outputting the same thing as prettier. They all decided to implement a different set of options, made different design decisions...

    So every time somebody mentioned using one of those, I was getting annoyed that I would --love-- to recommend them, but it wasn't going to be the same. And I believe from experience that one of the main reason Prettier has been so successful is because of this --very very very very-- laborious last few percent of edge cases.

    So goal #1 is to convince at least one of those projects to start being compatible with Prettier so that we had a viable alternative. In practice, there was no way I could talk to them directly and convince them to align with Prettier. So the idea of the bounty came to be, if I made a bounty big enough, it would be a way to convince them to do so (and it worked!).

    The bounty to work needs to be very easy to test (percentage of tests that pass is very easy to test), cannot easily be cheated (unless you run prettier itself, you need to go through the laborious work of doing the same logic) and cover real world use case (all the tests were added over time based on using it in prod). It also mentioned a "project" and not a "person" to encourage collaboration.

    It's a bit unorthodox but I've learned my lesson with code formatting that people are obsessed about discussing this topic so you need to find alternative ways to convince them.

    Now, going back to Prettier, I've been very annoyed that nobody had looked at performance of the project since after I stopped working on the project. For example, I wrote a way to keep the prettier process alive for editor integration instead of paying for the startup cost every single time https://github.com/prettier/prettier-rpc and nobody used it. I needed to find a way to convince people that prettier's performance actually matters.

    One of the most powerful way to get people to improve performance is to have two competing offerings battling against each others. We've seen this very successful between JS engines, JS frameworks... But, due to the success of prettier, there was no competition, the JS Survey admins even stopped asking about it because it was the only choice.

    So having a proper competitor which is faster and uses a relatively controversial language, was a good setup to get a competition going. And it also worked, since the bounty was announced, Fabio Spampinato got nerd snipped thinking he can make the JS version faster than Rust and has been working every day profiling and rewriting the Prettier CLI to be orders of magnitude faster. We are using the open collective money to contract him to work on this.

    Outside of performance, by having another group of people work on the same tests, they uncovered a lot of broken behaviors and edge cases on prettier that should be fixed.

    Last but not least, having a bounty incentivizing another project was intriguing enough to generate a lot of discussion and therefore receive a lot more coverage than just asking people to work on your project.

    ----

    So, overall, it achieved all the outcomes I wanted: by the end of the year, prettier itself is going to be a lot faster, and we actually have -less- fragmentation in the space where the other big project is now aligned in terms of the way code is formatted.

    Would have I been able to spend $10k more effectively, I can't think of how. But I'm pretty sure I'm missing some better strats!

  • difftastic

    a structural diff that understands syntax 🟥🟩

    If you're looking for a VS Code extension or a GitHub app, check out https://semanticdiff.com/. I'm a co-founder of this project.

    If you prefer a CLI tool, check out https://github.com/Wilfred/difftastic. It supports more languages, but doesn't recognize when code has been replaced by an equivalent version ("invariances"). So it will show some changes (e.g. replacing a character in a string with an escape sequence) even though they are technically equivalent.

  • SemanticDiff

    Community support for SemanticDiff, the programming language aware diff for Visual Studio Code.

    If you're looking for a VS Code extension or a GitHub app, check out https://semanticdiff.com/. I'm a co-founder of this project.

    If you prefer a CLI tool, check out https://github.com/Wilfred/difftastic. It supports more languages, but doesn't recognize when code has been replaced by an equivalent version ("invariances"). So it will show some changes (e.g. replacing a character in a string with an escape sequence) even though they are technically equivalent.

  • tsc-files

    A tiny tool to run `tsc` on specific files without ignoring tsconfig.json

    Tangental but for anyone using lint staged + typescript, I recommend tsc-files[1].

    [1]: https://github.com/gustavopch/tsc-files

  • Onboard AI

    ChatGPT with full context of any GitHub repo. Onboard AI learns any GitHub repo in minutes and lets you chat with it to locate functionality, understand different parts, and generate new code. Use it for free at app.getonboardai.com.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts