Open Jarred-Sumner opened 2 weeks ago
Feels like json5 could also be a good choice, that has a real spec at least. I realise there is no parser currently but surely it's better than having jsons that are not valid with most parsers
Regarding json5 vs jsonc, there is a related issue with some discussion about tsconfig.json from a few years ago:
Good design goals from yarn:
To achieve 3 it is useful to have a dedicated format and parser. Common formats, formats that support many options and functionality require additional logic, branches in the code, etc. which negatively affects the parsing speed.
Diffability at yarn.lock is simply top notch. Yes, commas in JSON fixes the situation from catastrophic to acceptable, but yarn.locks are always more compact and win in readability over JSON files.
The downside of a custom format is that if it is not compatible or is not a subset of some other, more common format, it will be harder to work with it at the user or infrastructure code level.
In any case, this undertaking cannot but rejoice.
This would really unblock bun for being usable in storybooks as parseable outputs are important for it to adopt as a supported package manager. https://github.com/storybookjs/storybook/issues/28164
JSON with trailing commas is good. But it's also important to have a --json
parameter on the package manager commands so scripts can JSON.parse
its output.
I'm not as familiar with the technical implications, but as a user I have to say that YAML makes a lot of sense in a long, auto-generated file like the lock file.
This is a tracking issue for implementing a text-based lockfile format for
bun install
and making it the default format going forward. There will be a smooth migration path frombun.lockb
→bun.lock
.Why?
When first working on the package manager, the flamegraph showed parsing JSON was the biggest number. So instead of a JSON lockfile, we designed two efficient binary formats: one for the registry manifest cache and one for the lockfile.
The binary lockfile format has served us well, but it isn't worth the cost in developer experience, particularly for larger teams working together. We suggest workarounds today for various things, but none of them are great.
bun.lockb.1
orbun.lockb.2
? What about both?bun install
and the lockfile has changes due to hashes changing, package.jsonscripts
changing, or other reasons and this is hard to understand right now because it's hard to read in a text editor.bun.lockb
to the.gitignore
fileWill bun install still be fast?
Yes.
Will it make bun install slower?
Based on what we've seen, about 1-20 milliseconds.
What will the new format be?
Probably JSON with Trailing Commas, like
tsconfig.json
.Bun already supports this schema format for the runtime (and package.json). TOML is another option and it's what we use for
bunfig.toml
, though I kind of think that was a mistake and it should've been JSON with Trailing Commas. TOML's editor tooling support is not as mature as JSON with Trailing Commas.Why JSON with Trailing Commas instead of JSON?
Too many collective human lifetimes have been spent fixing merge conflicts from diffs caused by adding or removing trailing commas at the end of lists in JSON
Why JSON with Trailing Commas instead of YAML?
YAML is fine. We don't have a YAML parser in Bun yet, and the indentation gets really confusing sometimes. Also, YAML parsers tend to be slower than JSON parsers (and YAML parsers are also JSON parsers). My favorite YAML fact is that the two-digit country code for Norway in YAML is parsed as
false
, though this isn't relevant to a lockfileWhy JSON with Trailing Commas instead of JSON5?
We don't have a JSON5 parser in Bun, and would like to avoid formats that're slower to parse than JSON
When will
bun.lock
be released?Q3.
What will the migration plan be?
bun install
will support bothbun.lockb
andbun.lock
for awhile, but once released, new features will only be supported viabun.lock
.Do people really edit lockfiles manually?
Yes, for small tweaks it can be important
Why not fix merge conflicts via
bun install
instead?We will support that as well. But, it shouldn't be impossible to do manually.