Support an "engines" field in package.json

[lgarron]

What is the problem this feature would solve?

In #5845 I was testing with an outdated version of bun. Although I was creating a project from scratch, it is possible to catch similar compatibility issues among developers of a given repo by using the "engines" field of package.json — in particular, bun could show a compatibility warning (optionally overridable) instead of erroring deep in implementation code.

For those of us testing various versions of bun, this could be particularly useful to avoid head-scratching situations. It's also just generally useful for any project that is using features of bun as they become available, if any of those projects are checked out by multiple developers or on multiple devices.

What is the feature you are proposing to solve the problem?

Support "bun" version ranges in the "engines" field of package.json for both the project and dependencies.

What alternatives have you considered?

Leave things as-is, especially if it's a performance concern?

[paperdave]

i dont think its a huge big deal, but right now yarn puts a warning for packages that use an unknonw engine. but this is the only package manager to do it.

otherwise, this is something we've thought about.

[adematte]

as most teams will end up with a mix of node and bun for their projects, this would make sense to support the engines field of package.json. Otherwise we are left with only README.md to indicate what version of bun or node (or both), we need to run a given project.

[Kleywalker]

Are there any plans to implement this feature?

[paperdave]

yes but probably not right now. i think it would be cool if bun in the engines field could be used to force the --bun flag for clis

[gornostay25]

@lgarron Any updates?

[strafe]

Seems like this is the only reasonable way to know which runtime a project is meant to be used with. For reproducibility's sake, this is kind of needed. Once this is done and bun is supported by corepack we can all sleep easy.

[vitch]

I came across this while trying to find a way to force all users of our monorepo to update to the newly released [email protected].

It looks like the oven-sh/setup-bun@v1 GitHub action searches package.json for the string bun@ in the packageManager field which is what corepack would use if corepack supported bun.

Is there any way to try and force all users to use a particular version of bun or should I add a test which checks Bun.version against package.json::packageManager or something?

[Kleywalker]

Is this being considered as a possible feature, and if so, will it be implemented in the near future?

[afonsojramos]

I came across this while trying to find a way to force all users of our monorepo to update to the newly released [email protected].

It looks like the oven-sh/setup-bun@v1 GitHub action searches package.json for the string bun@ in the packageManager field which is what corepack would use if corepack supported bun.

Is there any way to try and force all users to use a particular version of bun or should I add a test which checks Bun.version against package.json::packageManager or something?

@vitch Nice callout!

Found this in the setup-bun action, pay attention to the bum file, which references: https:/owenizedd/bum

Might be a good intermediate solution while bun itself doesn't add support to it.

Note: I'll try to setup the bun project locally today and try to work on this. Can't guarantee success as it will be the first dabble in Zig

[therealparmesh]

Related: It looks like corepack is likely going to be removed from the node distribution.

[wesleytodd]

I saw this issue because of the link in the comment above. In case folks hadn't seen this, a group of folks have been working on a more robust proposal to cover packageManager and related things. We are calling it devEngines and it looks to be acceptable by both the npm and pnpm teams. Worth considering in this conversation I would think.

openjs-foundation/package-metadata-interoperability-collab-space#15