support esnext module type #180
Conversation
| if ( !useModule && !useMain && !useJsnext ) { | ||
| throw new Error( `At least one of options.module, options.main or options.jsnext must be true` ); | ||
| if ( !useEsnext && !useModule && !useMain && !useJsnext ) { | ||
| throw new Error( `At least one of options.esnext, options.module, options.main or options.jsnext must be true` ); |
There was a problem hiding this comment.
I would sort them from the most to the least used: options.main, options.module, options.jsnext or options.esnext
| @@ -25,6 +25,10 @@ export default { | |||
| name: 'MyModule', | |||
| plugins: [ | |||
| resolve({ | |||
| // use "esnext" if possible | |||
There was a problem hiding this comment.
A quick description of the esnext would be useful. package.json entries are confusing enough.
Maybe something like:
// use "esnext" field for ES6 modules with non-transpiled ES6+ features if possible
// – see http://2ality.com/2017/06/pkg-esnext.html
esnext: true, // Default: false
// use "module" field for ES6 modules if possible
// – see http://2ality.com/2017/06/pkg-esnext.html
module: true, // Default: trueBut you can also take a look at the description I made for the ZURB Foundation documentation
|
In some respects, I feel uneasy about adding "yet another package field". Especially as it is "yet another option" Perhaps a better strategy is to align closer to webpack's strategy of offering a |
|
@keithamus I agree, but this would require discussions (new API), and takes some times to develop. So maybe we could merge this as it, and refactor the whole "entry points" API in a later pull request. |
|
If we merge this, then we are just adding API which we know we'll be deprecating. The new API is very straightforward if we just mimick what WebPack does. I'd rather fix it once the right way than introduce code now which we'll only delete in the next PR. |
|
I'm all for mainFields |
|
See #182 which implements |
|
@keithamus I absolutely agree with generalizing this into mainFields, very good point. |
I have a usecase where I need to use the esnext pkg field as suggested by http://2ality.com/2017/06/pkg-esnext.html .
I am developing web components with the help of skatejs, but without polyfills because I only need to support modern chrome. skatejs exports transpiled sources as module, and original code as esnext.
But the transpiled code does not run on modern browsers because it does not use class inheritance and calls HTMLElement constructor as function instead - which is not legal. So I really need to use the original code as contained in the skatejs package as esnext, controlling myself to which target the entire code packaged by rollup is transpiled.
I would be very happy if you would accept this patch for upstream.