search

oven-sh / bun

Incredibly fast JavaScript runtime, bundler, test runner, and package manager – all in one
https://bun.sh
Other
73.14k stars 2.68k forks source link

Support an `"engines"` field in `package.json` #5846

Open lgarron opened 12 months ago

lgarron commented 12 months ago

What is the problem this feature would solve?

In https://github.com/oven-sh/bun/issues/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 commented 12 months ago

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.

image

otherwise, this is something we've thought about.

adematte commented 11 months ago

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 commented 9 months ago

Are there any plans to implement this feature?

paperdave commented 9 months ago

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 commented 6 months ago

@lgarron Any updates?

strafe commented 6 months ago

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 commented 3 months ago

I came across this while trying to find a way to force all users of our monorepo to update to the newly released bun@1.1.9.

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 commented 2 months ago

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

afonsojramos commented 2 months ago

I came across this while trying to find a way to force all users of our monorepo to update to the newly released bun@1.1.9.

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://github.com/owenizedd/bum

image

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 commented 3 weeks ago

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

wesleytodd commented 3 weeks ago

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.

https://github.com/openjs-foundation/package-metadata-interoperability-collab-space/issues/15