Skip to content
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

Adopt a more generic approach? #9

Open
rauschma opened this issue Mar 30, 2017 · 5 comments
Open

Adopt a more generic approach? #9

rauschma opened this issue Mar 30, 2017 · 5 comments

Comments

@rauschma
Copy link

rauschma commented Mar 30, 2017

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.
@nolanlawson
Copy link

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.

@rauschma
Copy link
Author

rauschma commented Mar 30, 2017

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.

@rauschma
Copy link
Author

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.

@elektronik2k5
Copy link

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.)

@screendriver
Copy link

Maybe related to jsforum/jsforum#5? 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants