An option to use the "browser" and "esnext:browser" fields in package.json

[pygy]

Previously: rollup/rollup#185

It would be nice to get this.

Edit: wrong issue.

[Rich-Harris]

Have opened #14. It only adds support for browser, not esnext:browser – is that a thing?

[pygy]

Not yet, it was for symmetry... Weren't you the ones who came up with esnext:main?

[Rich-Harris]

jsnext:main – no, we didn't come up with it, it was a pre-existing (though not all that widely used) thing. I reckon it's probably better to hold off on jsnext:browser unless it starts to appear in the wild – experience suggests it will only cause confusion otherwise!

[nolanlawson]

It's worth mentioning that Webpack and Browserify both seem to treat the pkg.browser field slightly differently (see pouchdb/pouchdb#3287, pouchdb/pouchdb#4695, pouchdb/pouchdb#4700). I'm not sure if there's a consistent spec.

[pygy]

My use case is a WIP CSS auto-prefixer library for my CSS in JS library.

Server-side, I'll use a autoprefix derivative, and on the client something based on the much lighter (but browser-only) prefixfree... I also would like to offer the client library in both CommonJS and ES6 form (the latter in order to take advantage of Rollup's tree shaking)...

How would I achieve that without jsnext:browser ? Would jsnext:main take precedence on the browser field? I don't think that people will start using ES6 modules in Node code any time soon, anyway...

[nolanlawson]

FWIW, if we ever export jsnext:main in PouchDB, this would be a required feature for us as well. In our source code, we have probably 20-odd submodules that differ between the browser and Node.

Question: is there any reason we couldn't just use the pre-existing "browser" field for this?

[Victorystick]

@nolanlawson For the same reason that we cannot use "main" instead of "jsnext:main"; CommonJS instead of ES modules.

[nolanlawson]

@Victorystick, right, but the "browser" field only tells you "if you see this module, swap it out for this other module." Can't it just ignore CJS modules in ES6 mode, and vice versa? Or is that too tricky to implement?

[nolanlawson]

Just a quick note that I can confirm that the "browser" switch is at least working for me when I use rollup-plugin-commonjs and rollup-plugin-node-resolve. (Proof.) Nice work! Loving Rollup a lot; maybe we can start using it as a pure Browserify replacement. 😃

[letmaik]

If you have something like:

"main": "lib/index.js",
"jsnext:main": "src/index.js"
"browser": { "./lib/http.js": "./lib/http-browser.js" }

where src/ is ES6 code and lib/ transpiled code, then I don't see how you could do that without a separate "jsnext:browser": { "./src/http.js: "./src/http-browser.js" } field. Right?

[wearhere]

I second @letmaik's question—how can I support bundling ES6 and CJS modules for Node and the browser? Seems like jsnext:browser is required:

"main": "dist/node/index.js",
"jsnext:main": "dist/node/index.es2015.js",
"browser": "dist/browser/index.js",
"jsnext:browser": "dist/browser/index.es2015.js"

(Note that my package is not isomorphic, that’s why I'm using the browser field. I wish to output Node- and browser-specific modules in CJS and ES6 formats.)

[wearhere]

Actually let's move this discussion to #60.

[nolanlawson]

You can accomplish this by just putting all switches inside "browser". We do this in the PouchDB codebase and it works:

"main": "dist/node/index.js",
"jsnext:main": "dist/node/index.es2015.js",
"browser": {
  "dist/node/index.js": "dist/browser/index.js",
  "dist/node/index.es2015.js": "dist/browser/index.es2015.js"
}

[wearhere]

Neat @nolanlawson, it's nice to have a single browser field.

That does presume that jsnext:main exists though—that the developer is transpiling the Node module. This is not true in my case—the Node module predates the browser module and I don't wish to refactor it to an ES6 module.

How would you handle this case without jsnext:browser?

[fregante]

@wearhere I feel like this is an issue with legacy and it's not going anywhere because by the time you convince everyone to write and support a spec, the issue will be resolved (i.e. it's easier to refactor your node module into a ES6 module)