-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Expand usage of package.json exports
and engines
fields for runtimes
#36
Comments
exports
and engine
fields for runtimesexports
and engines
fields for runtimes
I think wintercg can and should set up an "official" list of engine names (like "edge-runtime", "node", etc), and as long as each platform that has a mechanism for specifying an engine combined with a semver range uses those engine names, it should be compliant. That way, the requirement wouldn't need to be "a package.json with an engines field", it'd just be "if you have a map of engine to semver range, here's what the names mean" |
👍 on "official" list of engine names. Ideally, I'd like us to also specify how they may be used in various contexts. I understand Deno does some fairly unique things with modules, but that Node, Edge Runtime, Bun, and Workers could all potentially share through the use of Follow up: discussion and thinking about this some more; I agree we shouldn't attempt to create some specification for |
It sounds like this could also be useful for embedded, so that a package could be tagged as compatible with embedded JavaScript engines and runtimes. Currently there's no definitive way to know an npm package can be used on embedded (many can) short of giving it a try. |
More concrete thoughts based on further disucssions:
|
When discussing internally, someone mentioned an example package that is already making use of quite a few unique keys in the package.json file. https://unpkg.com/browse/[email protected]/package.json Under This leads me to believe that many of the existing runtimes already have their key of choice. Can I draft something that documents these all in one place?
Vercel is agreeing internally what we want our key to be; when I draft the standard document I'll include Vercel's decision |
Are there any (official) references on those runtimes (other than node) utilizing the |
|
I couldn't find unfortunately (hence apart of the problem I'm trying to solve here). And I think you're right @ljharb - i just found the Webpack docs which reference |
This |
For Cloudflare Workers the name should be |
This was done! |
Lets get this added to the website: |
In short, I propose that we expand on the usage of the
exports
andengines
fields in package.json to support our various runtime environments. This would enable package authors to export their code to multiple runtimes simultaneously and have it all be defined from the samepackage.json
.This idea stems from the current
browser
andengine
property in package.json allowing Node.js package authors to specify (a) if their package can be used in a given browser environment, and (b) what version of node.js/npm the package works with.I'm not aware how all of the various runtimes currently handle dependency resolution, but at least for Vercel's edge runtime, we would like package authors to be able to specify that their package works with our runtime.
Here is an example. Given a (fake) package
vercel-sdk
, it is able to be used in both Node.js and Vercel Edge Runtime. For Node.js it relies upon APIs only available in v16.8+. For Vercel Edge Runtime, it works with v1. The exports for each runtime are also different. Based on the proposal I'd like to implement here is what thepackage.json
might look like.Vercel has a weighted interest in this feature as we look to further expand usage of Edge Runtime. No strict timeline, but I will be happy to do the work and push this through. Let me know what y'all think!
The text was updated successfully, but these errors were encountered: