Webpack 2 #861

Merged
merged 90 commits into from Nov 6, 2015

Conversation

Projects
None yet
@sokra
Member

sokra commented Mar 6, 2015

No description provided.

sokra and others added some commits Jan 12, 2015

Merge remote-tracking branch 'remotes/origin/harmony'
Conflicts:
	lib/Parser.js
	package.json
allow config file to export a function
pass --env to config function
Merge branch 'hot-multi-pass' of https://github.com/webpack/webpack.git
… into webpack-2

Conflicts:
	lib/Compilation.js
@jhnns

This comment has been minimized.

Show comment
Hide comment
@jhnns

jhnns Mar 6, 2015

Member

Woot woot woot!

Hottest changes (taken from the commit log) are:

  • switched to acorn for it's better es6 support
  • ES6 parser, ES6 modules
  • disable full dynamic require by default (require(expr))

and

  • test it too 😉

Did you experience any performance benefits/penalties from switching to acorn? What is actually breaking with 2.0.0?

Member

jhnns commented Mar 6, 2015

Woot woot woot!

Hottest changes (taken from the commit log) are:

  • switched to acorn for it's better es6 support
  • ES6 parser, ES6 modules
  • disable full dynamic require by default (require(expr))

and

  • test it too 😉

Did you experience any performance benefits/penalties from switching to acorn? What is actually breaking with 2.0.0?

@jhnns

This comment has been minimized.

Show comment
Hide comment
@jhnns

jhnns Mar 6, 2015

Member

Btw: I tested this branch in a fairly big project and it worked without changing anything. 👍

Member

jhnns commented Mar 6, 2015

Btw: I tested this branch in a fairly big project and it worked without changing anything. 👍

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Mar 6, 2015

Member

What is actually breaking with 2.0.0?

Only the uncool stuff... If you are only using cool stuff, it propably still works...
But there are more changes coming...

Member

sokra commented Mar 6, 2015

What is actually breaking with 2.0.0?

Only the uncool stuff... If you are only using cool stuff, it propably still works...
But there are more changes coming...

@MoOx

This comment has been minimized.

Show comment
Hide comment
@MoOx

MoOx Mar 11, 2015

Contributor

Did you take a look to espree that have a full es6 support now ?

Contributor

MoOx commented Mar 11, 2015

Did you take a look to espree that have a full es6 support now ?

@eugene1g

This comment has been minimized.

Show comment
Hide comment
@eugene1g

eugene1g Mar 17, 2015

Great. Just tested in our quite complex build - no issues. The only difference was the change in cache hashes, possibly because of the change to the OccurenceOrderPlugin.

Great. Just tested in our quite complex build - no issues. The only difference was the change in cache hashes, possibly because of the change to the OccurenceOrderPlugin.

@@ -1,9 +1,10 @@
require("should");
it("should provide a global Buffer shim", function () {
- Buffer.should.be.a.Function;
+ Buffer.should.be.an.Function;

This comment has been minimized.

@akre54

akre54 Mar 19, 2015

Contributor

"a" is the correct usage here since Function doesn't start with a vowel.

@akre54

akre54 Mar 19, 2015

Contributor

"a" is the correct usage here since Function doesn't start with a vowel.

This comment has been minimized.

@jhnns

jhnns Mar 21, 2015

Member

^^

sokra added some commits Mar 22, 2015

This was referenced Apr 9, 2015

@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Nov 6, 2015

Member

While we're suggesting tools for automating the changelog, I recommend semantic-release by @boennemann. You integrate it with CI (like travis) and when new code gets into master (WIP branch gets merged), it analyses your commit messages since the last release to determine the kind of release that needs to take place, publishes that release to npm and GitHub complete with a CHANGELOG on GitHub's releases page.

The commit message convention is solid, reasonable, and easy. And there's even a CLI for generating it with a prompt (see commitizen).

Warning... Self promo ... I have a free egghead.io series that covers how to set all of this up: How to Write an Open Source JavaScript Library

Member

kentcdodds commented Nov 6, 2015

While we're suggesting tools for automating the changelog, I recommend semantic-release by @boennemann. You integrate it with CI (like travis) and when new code gets into master (WIP branch gets merged), it analyses your commit messages since the last release to determine the kind of release that needs to take place, publishes that release to npm and GitHub complete with a CHANGELOG on GitHub's releases page.

The commit message convention is solid, reasonable, and easy. And there's even a CLI for generating it with a prompt (see commitizen).

Warning... Self promo ... I have a free egghead.io series that covers how to set all of this up: How to Write an Open Source JavaScript Library

@jhnns

This comment has been minimized.

Show comment
Hide comment
@jhnns

jhnns Nov 7, 2015

Member

I agree. A changelog with reliable information about breaking changes is vital for a large project like webpack and its ecosystem.

Member

jhnns commented Nov 7, 2015

I agree. A changelog with reliable information about breaking changes is vital for a large project like webpack and its ecosystem.

@webpro

This comment has been minimized.

Show comment
Hide comment
@webpro

webpro Nov 7, 2015

Sorry, off-topic as well re: automated releases. To have the git commits be the changelog without changing commit message behavior, release-it might suit needs without much friction.

webpro commented Nov 7, 2015

Sorry, off-topic as well re: automated releases. To have the git commits be the changelog without changing commit message behavior, release-it might suit needs without much friction.

@ronkorving

This comment has been minimized.

Show comment
Hide comment
@ronkorving

ronkorving Nov 11, 2015

Contributor

unused?
Not part of this PR but just noticed this here...

unused?
Not part of this PR but just noticed this here...

@taion taion referenced this pull request in ReactTraining/react-router Nov 16, 2015

Closed

ES6 module build #2524

@phaistonian

This comment has been minimized.

Show comment
Hide comment
@phaistonian

phaistonian Dec 5, 2015

Any chance the beta will make it to NPM?

Any chance the beta will make it to NPM?

@dtothefp

This comment has been minimized.

Show comment
Hide comment
@dtothefp

dtothefp Dec 5, 2015

@phaistonian agreed would be great to get a beta published to NPM. I tried to install this in my project at work from the referencing the github repo but because the package.json version got bumped to 2.0.1-beta every webpack loader that lists webpack as a peer dependency, which is pretty much all of them I'm assuming, yells and the package won't install.

dtothefp commented Dec 5, 2015

@phaistonian agreed would be great to get a beta published to NPM. I tried to install this in my project at work from the referencing the github repo but because the package.json version got bumped to 2.0.1-beta every webpack loader that lists webpack as a peer dependency, which is pretty much all of them I'm assuming, yells and the package won't install.

@gnunicorn gnunicorn referenced this pull request in beavyHQ/beavy Dec 9, 2015

Open

test out webpack2 #62

@dschissler dschissler referenced this pull request in aurelia/skeleton-navigation Dec 25, 2015

Closed

aurelia + webpack #41

@catamphetamine

This comment has been minimized.

Show comment
Hide comment
@catamphetamine

catamphetamine Jan 4, 2016

had to hack a lot of google to find any information on "webpack 2 new features" and got here.
tree shaking is cool.

had to hack a lot of google to find any information on "webpack 2 new features" and got here.
tree shaking is cool.

@klimashkin

This comment has been minimized.

Show comment
Hide comment
@klimashkin

klimashkin Jan 8, 2016

@sokra I have a quick question about tree-shaking
Assume, that we have folder /pages with dozen of modules and index.js module in it with re-exporting list of all other modules like

export module1 from './module1';
export module2 from './module2';

And some upper-level script makes import {module1} from './pages';. Will module2 be eliminated from build and from page/index.js re-export list with tree-shaking?

@sokra I have a quick question about tree-shaking
Assume, that we have folder /pages with dozen of modules and index.js module in it with re-exporting list of all other modules like

export module1 from './module1';
export module2 from './module2';

And some upper-level script makes import {module1} from './pages';. Will module2 be eliminated from build and from page/index.js re-export list with tree-shaking?

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Jan 8, 2016

Member

@klimashkin no. Only the exports of module2 will be omitted.

Removing module2 totally would be an unsafe operation, because module2 could contain side-effects that wouldn't be executed.

I plan to offer is kind of unsafe optimization as opt-in plugin, but there is nothing there yet.


In my opinion the ES6 spec failed here as it doesn't allow this optimization... (Would be difficult to apply in a dynamic system, but possible in a static system like webpack)

Member

sokra commented Jan 8, 2016

@klimashkin no. Only the exports of module2 will be omitted.

Removing module2 totally would be an unsafe operation, because module2 could contain side-effects that wouldn't be executed.

I plan to offer is kind of unsafe optimization as opt-in plugin, but there is nothing there yet.


In my opinion the ES6 spec failed here as it doesn't allow this optimization... (Would be difficult to apply in a dynamic system, but possible in a static system like webpack)

@klimashkin

This comment has been minimized.

Show comment
Hide comment
@klimashkin

klimashkin Jan 8, 2016

You mean only re-export will be omitted, or both - export and re-export but not module itself?

You mean only re-export will be omitted, or both - export and re-export but not module itself?

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Jan 8, 2016

Member

export and re-export but not module itself?

yes

Member

sokra commented Jan 8, 2016

export and re-export but not module itself?

yes

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Jan 8, 2016

Member

Omitting exports of a module allows uglifys dead code elimination to remove side-effect free code.

Member

sokra commented Jan 8, 2016

Omitting exports of a module allows uglifys dead code elimination to remove side-effect free code.

@JamesHenry

This comment has been minimized.

Show comment
Hide comment
@JamesHenry

JamesHenry Jan 8, 2016

@sokra is there somewhere specific where we should look out for more info on Webpack 2?

I am happy to help start something if not. It would obviously be great for everyone involved if there was somewhere other than this merged PR where knowledge could be shared and you were not responsible for answering ad hoc questions :)

I was already able to start using webpack 2 on my app without any functional problems which is great, but I had to remove it again as the npm errors from things like webpack-dev-server became too much whenever installing new dependencies. I can see @dtothefp had the same experience.

Would it possible to get webpack2 versions of other "webpack products" like the dev server set up on npm?

PS. Thanks again for all your amazing work on webpack - for me, it is one of the most impressive frontend projects around

@sokra is there somewhere specific where we should look out for more info on Webpack 2?

I am happy to help start something if not. It would obviously be great for everyone involved if there was somewhere other than this merged PR where knowledge could be shared and you were not responsible for answering ad hoc questions :)

I was already able to start using webpack 2 on my app without any functional problems which is great, but I had to remove it again as the npm errors from things like webpack-dev-server became too much whenever installing new dependencies. I can see @dtothefp had the same experience.

Would it possible to get webpack2 versions of other "webpack products" like the dev server set up on npm?

PS. Thanks again for all your amazing work on webpack - for me, it is one of the most impressive frontend projects around

@dtothefp

This comment has been minimized.

Show comment
Hide comment
@dtothefp

dtothefp Jan 8, 2016

@JamesHenry I agree would be great to have a beginning knowledge share i.e. New stuff and deprecated plugins/syntax. Also as I mentioned earlier a beta version on npm would be useful because for large projects installing dependency directly from github repo is a no go.

As for your dev server issues switching to webpack middleware and hot middleware may solve your problems, seems to be a more configurable alternative

https://github.com/webpack/webpack-dev-middleware
https://www.npmjs.com/package/webpack-hot-middleware

dtothefp commented Jan 8, 2016

@JamesHenry I agree would be great to have a beginning knowledge share i.e. New stuff and deprecated plugins/syntax. Also as I mentioned earlier a beta version on npm would be useful because for large projects installing dependency directly from github repo is a no go.

As for your dev server issues switching to webpack middleware and hot middleware may solve your problems, seems to be a more configurable alternative

https://github.com/webpack/webpack-dev-middleware
https://www.npmjs.com/package/webpack-hot-middleware

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Jan 8, 2016

Member

It would obviously be great for everyone involved if there was somewhere other than this merged PR where knowledge could be shared and you were not responsible for answering ad hoc questions :)

I'll write a larger article about webpack 2 once it's finished.

PS: Here is more info, for the curious one: https://docs.google.com/document/d/1tRc0MzvRdGK7EbG2LRW8vSyoxKhR_EvRUz3AQRyFZso/edit

Member

sokra commented Jan 8, 2016

It would obviously be great for everyone involved if there was somewhere other than this merged PR where knowledge could be shared and you were not responsible for answering ad hoc questions :)

I'll write a larger article about webpack 2 once it's finished.

PS: Here is more info, for the curious one: https://docs.google.com/document/d/1tRc0MzvRdGK7EbG2LRW8vSyoxKhR_EvRUz3AQRyFZso/edit

@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Jan 8, 2016

Member

@sokra, I'm interested in why this was decided:

webpack differs from the ES6 modules spec: imports are not hoisted

Seems like a bad call to me, but I'm sure I'm out of context.

Member

kentcdodds commented Jan 8, 2016

@sokra, I'm interested in why this was decided:

webpack differs from the ES6 modules spec: imports are not hoisted

Seems like a bad call to me, but I'm sure I'm out of context.

@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Jan 8, 2016

Member

Also, for:

  • add “es6:main” field as default package main
    • Name?

I may have missed earlier discussion on this, but for the name I thought I'd just bring up the fact that we'll need to revisit this again every year for each new version of the spec. I imagine this has been considered, but I thought I'd just bring it up just in case. May not be a bad thing.

Member

kentcdodds commented Jan 8, 2016

Also, for:

  • add “es6:main” field as default package main
    • Name?

I may have missed earlier discussion on this, but for the name I thought I'd just bring up the fact that we'll need to revisit this again every year for each new version of the spec. I imagine this has been considered, but I thought I'd just bring it up just in case. May not be a bad thing.

@phaistonian

This comment has been minimized.

Show comment
Hide comment
@phaistonian

phaistonian Jan 9, 2016

@sokra Wondering: will the "tree shaking" support result in bundle sizes comparable to the ones Rollup claims to get?

Because, the way I see it, that's their main selling point.

@sokra Wondering: will the "tree shaking" support result in bundle sizes comparable to the ones Rollup claims to get?

Because, the way I see it, that's their main selling point.

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Jan 9, 2016

Member

webpack differs from the ES6 modules spec: imports are not hoisted

In this example:

imports "a";
require("b");
imports "c";

The Spec says execution order is: a, c, b.

Currently webpack differs from the spec by using the execution order: a, b, c. I hope this makes incremental transition to ES6 easier.


ill the "tree shaking" support result in bundle sizes comparable to the ones Rollup claims to get?

Sadly not. webpack need to support CJS and AMD too. These styles are pretty dynamic, which requires wrapping in functions to control the execution time. An idea is to add ES6 modules as output target to webpack (still difficult) and run rollbar on the result.

Member

sokra commented Jan 9, 2016

webpack differs from the ES6 modules spec: imports are not hoisted

In this example:

imports "a";
require("b");
imports "c";

The Spec says execution order is: a, c, b.

Currently webpack differs from the spec by using the execution order: a, b, c. I hope this makes incremental transition to ES6 easier.


ill the "tree shaking" support result in bundle sizes comparable to the ones Rollup claims to get?

Sadly not. webpack need to support CJS and AMD too. These styles are pretty dynamic, which requires wrapping in functions to control the execution time. An idea is to add ES6 modules as output target to webpack (still difficult) and run rollbar on the result.

@phaistonian

This comment has been minimized.

Show comment
Hide comment
@phaistonian

phaistonian Jan 9, 2016

@sokra Running rollbar on the result sounds the most "logical" way to go, though mashing up 2 bundlers would feel a bit ..dirty.

Is there an estimation of % slower bundling in production will be since tree shaking will be involved?

Oh, one little thing I noticed (could be because of glitch) is that the optimize.OccurenceOrderPlugin fails (not found) in 2.0.

Will re-check on this one later though.

ps: yay for auto applying NODE_ENV=production on -p :)

@sokra Running rollbar on the result sounds the most "logical" way to go, though mashing up 2 bundlers would feel a bit ..dirty.

Is there an estimation of % slower bundling in production will be since tree shaking will be involved?

Oh, one little thing I noticed (could be because of glitch) is that the optimize.OccurenceOrderPlugin fails (not found) in 2.0.

Will re-check on this one later though.

ps: yay for auto applying NODE_ENV=production on -p :)

@danieljuhl

This comment has been minimized.

Show comment
Hide comment
@danieljuhl

danieljuhl Jan 9, 2016

@phaistonian Have you seen issue #53 in webpack docs? webpack/docs#53
OccurenceOrderPlugin -> OccurrenceOrderPlugin

@phaistonian Have you seen issue #53 in webpack docs? webpack/docs#53
OccurenceOrderPlugin -> OccurrenceOrderPlugin

@dtothefp

This comment has been minimized.

Show comment
Hide comment
@dtothefp

dtothefp Jan 9, 2016

@phaistonian if you want to read more fine grained details you should have a look here rollup/rollup#219 (comment). @sokra actually pitches in to this conversation on roll up. Seems to me roll up is a good solution if you are only worried about making es6 JS bundles with no extras and will also be a nice tool if you are using http2 and doing only light bundling of commonly grouped modules. For the rest of us who use http1 and also, more importantly, use webpack for many invaluable tools such as scss compilation/local css/public path replacement, image/font handling via file & url loader, patching of non commonjs/AMD non compliant modules, and isomorphic compilation I think webpack will remain an invaluable tool.

If you are really concerned about boilerplate bloating your code you can look into CommonsChunksPlugin and generate a vendor bundle that you can cache heavily. Not sure how much this helps with the substitution of exports/imports from es6 to commonjs syntax in each file but it does chunk out some webpack runtime as far as I can tell and eliminates potentially bundling twice a library that is imported into multiple bundle entry points

dtothefp commented Jan 9, 2016

@phaistonian if you want to read more fine grained details you should have a look here rollup/rollup#219 (comment). @sokra actually pitches in to this conversation on roll up. Seems to me roll up is a good solution if you are only worried about making es6 JS bundles with no extras and will also be a nice tool if you are using http2 and doing only light bundling of commonly grouped modules. For the rest of us who use http1 and also, more importantly, use webpack for many invaluable tools such as scss compilation/local css/public path replacement, image/font handling via file & url loader, patching of non commonjs/AMD non compliant modules, and isomorphic compilation I think webpack will remain an invaluable tool.

If you are really concerned about boilerplate bloating your code you can look into CommonsChunksPlugin and generate a vendor bundle that you can cache heavily. Not sure how much this helps with the substitution of exports/imports from es6 to commonjs syntax in each file but it does chunk out some webpack runtime as far as I can tell and eliminates potentially bundling twice a library that is imported into multiple bundle entry points

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Jan 9, 2016

Member

is that the optimize.OccurenceOrderPlugin fails (not found) in 2.0.

No longer needed, is default.

Member

sokra commented Jan 9, 2016

is that the optimize.OccurenceOrderPlugin fails (not found) in 2.0.

No longer needed, is default.

@phaistonian

This comment has been minimized.

Show comment
Hide comment
@phaistonian

phaistonian Jan 10, 2016

@dtothefp Thank you for your pointers and input.

I do use CommonsChunksPlugin and, for what it's worth, I believe Webpack is the most exciting technology we have seen lately (this and React).

It's not about comparing bundlers, it's about being excited as to what could be done (if any) in order to get the best of both worlds in the world you need/love the most (Webpack).

@sokra: Speaking of defaults, perhaps HotModuleReplacementPlugin should also come as default (one day) in dev environment.

@dtothefp Thank you for your pointers and input.

I do use CommonsChunksPlugin and, for what it's worth, I believe Webpack is the most exciting technology we have seen lately (this and React).

It's not about comparing bundlers, it's about being excited as to what could be done (if any) in order to get the best of both worlds in the world you need/love the most (Webpack).

@sokra: Speaking of defaults, perhaps HotModuleReplacementPlugin should also come as default (one day) in dev environment.

@graue

This comment has been minimized.

Show comment
Hide comment
@graue

graue Jan 26, 2016

Do I need any special configuration to enable System.import? Tried it and it just compiles directly to System['import'], then fails at runtime with ReferenceError: System is not defined.

graue commented Jan 26, 2016

Do I need any special configuration to enable System.import? Tried it and it just compiles directly to System['import'], then fails at runtime with ReferenceError: System is not defined.

@sokra

This comment has been minimized.

Show comment
Hide comment
@dtothefp

This comment has been minimized.

Show comment
Hide comment
@dtothefp

dtothefp Jan 31, 2016

@sokra awesome....thanks for the gist!!!

@sokra awesome....thanks for the gist!!!

@BenoitZugmeyer

This comment has been minimized.

Show comment
Hide comment
@BenoitZugmeyer

BenoitZugmeyer Jan 31, 2016

@sokra it looks awesome!

  • I would rewrite the System.import example in Code Splitting with ES6. Since the .catch does not return anything, the .then will be called with undefined as first argument if the module fails to load.
  • s/comsuming/consuming

@sokra it looks awesome!

  • I would rewrite the System.import example in Code Splitting with ES6. Since the .catch does not return anything, the .then will be called with undefined as first argument if the module fails to load.
  • s/comsuming/consuming
@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Feb 1, 2016

Member

@BenoitZugmeyer thanks, updated it.

Member

sokra commented Feb 1, 2016

@BenoitZugmeyer thanks, updated it.

@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Feb 1, 2016

Member

I've forked it and fixed various spelling and grammatical errors (see changes here, in some cases I'm being nit-picky just because I expect this document will be used for documentation in the future). Also changed CommonJs to CommonJS as that's the most common casing (from what I can tell).

I had some items of feedback/questions if it's not too late:

  • Seems odd that the --env flag behaves differently if there's only one vs having multiple. I would prefer that it always results in an object. I feel like keeping it consistent would help reduce confusion.
  • I'm unsure of the use/need of aliasFields when you can already provide an array of mainFields. The document didn't seem to explain it well enough for me at least.
  • Rename moduleExtensions to moduleSuffix. In my mind extension maps to a file extension (like .js or .css). A suffix seems to be more appropriate for what this is actually for (this change would also require that enforceModuleExtension is changed to enforceModuleSuffix).
  • the configuration file resp. thecontextoption I wasn't sure what this phrase is supposed to say. What is resp. short for?

Looks great! I'm really excited to try this out :D

Member

kentcdodds commented Feb 1, 2016

I've forked it and fixed various spelling and grammatical errors (see changes here, in some cases I'm being nit-picky just because I expect this document will be used for documentation in the future). Also changed CommonJs to CommonJS as that's the most common casing (from what I can tell).

I had some items of feedback/questions if it's not too late:

  • Seems odd that the --env flag behaves differently if there's only one vs having multiple. I would prefer that it always results in an object. I feel like keeping it consistent would help reduce confusion.
  • I'm unsure of the use/need of aliasFields when you can already provide an array of mainFields. The document didn't seem to explain it well enough for me at least.
  • Rename moduleExtensions to moduleSuffix. In my mind extension maps to a file extension (like .js or .css). A suffix seems to be more appropriate for what this is actually for (this change would also require that enforceModuleExtension is changed to enforceModuleSuffix).
  • the configuration file resp. thecontextoption I wasn't sure what this phrase is supposed to say. What is resp. short for?

Looks great! I'm really excited to try this out :D

@karlhorky

This comment has been minimized.

Show comment
Hide comment
@karlhorky

karlhorky Feb 1, 2016

Maybe resp. is short for 'respective of'?

Maybe resp. is short for 'respective of'?

@sokra

This comment has been minimized.

Show comment
Hide comment
@sokra

sokra Feb 2, 2016

Member

Thanks for the corrections, merged your fork.

Seems odd that the --env flag behaves differently if there's only one vs having multiple. I would prefer that it always results in an object. I feel like keeping it consistent would help reduce confusion.

I just pass along the value I get from CLI parsing (yargs). Objects are possible because the lib support them (https://www.npmjs.com/package/yargs#dot-notation).
--env abc => "abc"
--env => true
--env 123 => 123
--env.hello => {hello: true}
--env.hello world => {hello: "world"}

I'm unsure of the use/need of aliasFields when you can already provide an array of mainFields. The document didn't seem to explain it well enough for me at least.

I added an additional sentense.

"browser": {
  "fs": false,
  "./index.js": "./browser.js"
}
Member

sokra commented Feb 2, 2016

Thanks for the corrections, merged your fork.

Seems odd that the --env flag behaves differently if there's only one vs having multiple. I would prefer that it always results in an object. I feel like keeping it consistent would help reduce confusion.

I just pass along the value I get from CLI parsing (yargs). Objects are possible because the lib support them (https://www.npmjs.com/package/yargs#dot-notation).
--env abc => "abc"
--env => true
--env 123 => 123
--env.hello => {hello: true}
--env.hello world => {hello: "world"}

I'm unsure of the use/need of aliasFields when you can already provide an array of mainFields. The document didn't seem to explain it well enough for me at least.

I added an additional sentense.

"browser": {
  "fs": false,
  "./index.js": "./browser.js"
}
@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Feb 2, 2016

Member

Thanks for answering my questions @sokra! I think I misunderstood the --env flag. I'm good with what you've described 👍

- // The content of these field is an object where requests to a key are mapped to the corresponding value
+ // The content of this field is an object where requests to a key are mapped to the corresponding value

I hope you're ok with the nit-picking. Let me know if this isn't the time or place to be nit-picky and feel free to ignore my suggestions altogether :-)

Also, what do you think of my other suggestion?

Rename moduleExtensions to moduleSuffix. In my mind extension maps to a file extension (like .js or .css). A suffix seems to be more appropriate for what this is actually for (this change would also require that enforceModuleExtension is changed to enforceModuleSuffix).

Member

kentcdodds commented Feb 2, 2016

Thanks for answering my questions @sokra! I think I misunderstood the --env flag. I'm good with what you've described 👍

- // The content of these field is an object where requests to a key are mapped to the corresponding value
+ // The content of this field is an object where requests to a key are mapped to the corresponding value

I hope you're ok with the nit-picking. Let me know if this isn't the time or place to be nit-picky and feel free to ignore my suggestions altogether :-)

Also, what do you think of my other suggestion?

Rename moduleExtensions to moduleSuffix. In my mind extension maps to a file extension (like .js or .css). A suffix seems to be more appropriate for what this is actually for (this change would also require that enforceModuleExtension is changed to enforceModuleSuffix).

@banricho banricho referenced this pull request in Aphasia2015/webLog Feb 5, 2016

Open

学习模块化规范和打包工具 #12

@borisirota borisirota referenced this pull request in ramda/ramda Feb 6, 2016

Closed

Make ramda more modular #1505

dignifiedquire referenced this pull request in ipfs/js-ipfs-repo May 2, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment