Skip to content

Clarify the meaning of Rule.parser options #1489

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

Merged
merged 1 commit into from
Aug 6, 2017

Conversation

jennings
Copy link
Collaborator

@jennings jennings commented Aug 6, 2017

I think this wording might clarify the text mentioned in #1484.

Copy link
Collaborator

@skipjack skipjack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jennings great, thank you! I think this change definitely resolves #1484.

@skipjack skipjack merged commit d6f9075 into webpack:master Aug 6, 2017
@jennings jennings deleted the issue-1484-parser-options branch August 6, 2017 21:29
dear-lizhihua referenced this pull request in docschina/webpack.js.org Aug 10, 2017
* docs(config): change `global` to `root` in externals  (#1214)

The currently deployed documentation indicates that there are 
4 module contexts you can specify under the externals config...

- `global`
- `commonjs`
- `commonjs2`
- `amd`

... which contradicts both the examples that surround it, and the 
actual library functionality. 

This just changes the word "global" to "root" in the section that lists 
the module contexts.

* docs(config): clarify that HMR plugin can be added via a flag (#1478)

* fix(markdown): resolve some odd code display bugs (#1486)

Fix list formatting in `/development/plugin-patterns/`. Remove the
`inline-block` declaration to let inline code flow more naturally
and prevent this odd wrapping if other badly formatted lists slip in.

* docs(guides): add note about chunkFilename (#1483)

* docs(config): clarify the meaning of `Rule.parser` options (#1489)

Fixes #1484

* docs(config): improve node documentation (#1368)

The documentation about using built-in Node.js modules was very poor
(i.e. non-existent). This expands the documentation of the "node"
configuration option, and shows how one can require built-in modules if
desired.

Furthermore, all possible effects of the options are explicitly
documented. Instead of being vague of what happens when `false` is used,
it is explicitly spelled out what happens.

References:

-
https://github.com/webpack/webpack/blob/a589a6c9789a9d342fc630e36ab81827dd20289b/lib/WebpackOptionsApply.js
  shows when the NodeStuffPlugin and NodeSourcePlugin plugins are used.
- https://github.com/webpack/webpack/blob/a589a6c9789a9d342fc630e36ab81827dd20289b/lib/NodeStuffPlugin.js
  is the plugin that is used for every target.
- https://github.com/webpack/webpack/blob/a589a6c9789a9d342fc630e36ab81827dd20289b/lib/node/NodeSourcePlugin.js
  is the plugin that is only used for "web" and "webworker" targets.
- https://github.com/webpack/webpack/blob/a589a6c9789a9d342fc630e36ab81827dd20289b/lib/MultiModule.js#L65-L67
  is the generated "webpackMissingModule" code for unresolved modules.
  (when the NodeSourcePlugin is not used, the environment's "require" is
  used. In Node.js, this also throws a "Cannot find module 'modulename'"
  error (with single quotes instead of double quotes)).

* docs(config): correct substitutions in output.md (#1487)

Correct `output.filename` substitutions and move the others to
`output.sourceMapFilename`. Also fix `related` link in the context-
replacement-plugin.

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

Successfully merging this pull request may close these issues.

2 participants