Ideas for Bun v1.2

[fel1x-developer]

Dear Bun core members,

From the latest release note, I read that

Bun.sql will be released in Bun v1.2 - coming in 13 days at the time of writing.

So the release of Bun v1.2 is imminent, happening in two weeks.

I have suggestions for the v1.2 release, which can significantly improve the user/developer experience in using Bun.

The new lockfile

1. From an article from the Bun blog:

We're planning to make bun.lock the default in Bun v1.2.0.

I suggest removing --save-text-lockfile option for bun install and introduce --save-binary-lockfile for bun.lockb compatibility.

2. All bun.lockb files in oven-sh/bun repo should be replaced with bun.lock (text lockfile) before the 1.2.0 release.
   Currently, there are 41 bun.lockb files (including for tests).

➜ find . -name "bun.lockb" | wc -l
      41

Semantic versioning for Bun

I have always been wondering why Bun's versioning policy is a bit different from the de facto semantic versioning (semver) that is widely used in node/npm ecosystem.

NPM says:

we recommend publishing a new version of the package with an updated version number in the package.json file that follows the semantic versioning spec.

In semantic versioning, a patch release is for "Backward compatible bug fixes" while minor release is for "Backward compatible new features" and major release is for "Changes that break backward compatibility".

The 43 patch releases in Bun since v1.1.0 introduced many new features and bug fixes while maintaining backward compatibility. According to semantic versioning, most of the releases should have been minor releases. For example, Bun 1.1.39 should have been a minor release while releases like 1.1.42 can remain as a minor release.

Bun v1.2.0 will have some breaking changes, such as making text lockfile default option for bun install. (more breaking changes can be found here I think the new version of Bun should be released as v2.0.0, not v1.2.0, and follow semantic versioning policy for future releases.

This has two advantages that benefit end users.

1. Users can expect what the update is about. For example, they will know it's a bug fix if there is a new release 2.0.1 from 2.0.0. They can expect a new feature from minor release like 2.1.0 from 2.0.0. This helps users save time from reading the whole release note from top to bottom before upgrading bun since the semantic versioning hints them what the release is about.

2. Semantic versioning is the de facto standard for NPM ecosystem, and there are packages that install bun from package.json. By convention, they expect bug fixes only from "bun": "~2.0.0", but under the current Bun versioning policy, this can introduce new features which the end users do not expect. We should follow NPM's recommendation, again:

we recommend publishing a new version of the package with an updated version number in the package.json file that follows the semantic versioning spec.

I found that open source projects like Svelte make releases while strictly sticking with the semantic versioning policy.

Open sourcing the website

Many open source projects make the source code for their website public. (e.g. nodejs.org, svelte.dev, hono.dev)

Should Bun open source its website as well?