defunctzombie / package-browser-field-spec

Spec document for the 'browser' field in package.json
437 stars 20 forks source link

Adopt a more generic approach? #9

Open rauschma opened 7 years ago

rauschma commented 7 years ago

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:

nolanlawson commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Maybe related to https://github.com/jsforum/jsforum/issues/5? 🤔