Adopt a more generic approach?
rauschma opened this issue · comments
I’d love to have something like this:
"engines": {
"node >= 0.10.3, node < 0.12": {
"main": "./es5/index.js",
"bin": { "foo": "./es5/bin/foo.js" }
},
"ecmascript >= 2015": {
"main": "./es2015/index.js",
"bin": { "foo": "./es2015/bin/foo.js" }
}
},An additional entry (similar to "main") could be "files", which would work like "browser".
Use cases:
- Node.js: deliver the same module for several versions of Node.js.
- Browsers: deliver both a native (e.g. ES5) version and another “bleeding edge” version, to be transpiled via Babel.
- Browsers: allow new libraries to age gracefully – transpile only as long your target platforms don’t support the features, yet.
- All platforms: deliver both a CommonJS and an ES module version.
What does "bin" solve that isn't already solved by "engines"/"bin"? May be a bit simpler if the proposal were restricted to browser bundles.
The idea is to deliver different binaries for different versions of Node.js, within the same package. Personally, I don’t have a need for it. It could probably be omitted in a first version of a standard and be added later, should it become necessary.
I like the idea of starting with browser bundles. Then "engines" is probably not a good name, because it clashes with Node, at the moment. It should be neutral enough, though, that adding support for Node later doesn’t feel weird.
I think it is the right direction, but we should adopt a more granular/modular approach.
ES2015 may indeed be transpiled to ES5, except for Proxies. Same goes for other modern features for a target ES3 runtime.
So I'm thinking of something like autoprefixer, plus a way to alert the user that a given source feature to destination runtime transformation is impossible (i.e. an error message like Looks like you're targeting browser <FOO> but module <BAR> requires feature <BAZ>, which can't be transpiled.)
Maybe related to jsforum/jsforum#5? 🤔