This repository has been archived by the owner on Feb 18, 2024. It is now read-only.
Support specifying plugins by path #102
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This allows the expensive require()s to be skipped in cases where the plugin or webpack configuration won't end up being used. For example, using this feature in Neutrino reduces the overhead of dynamically generating `.eslintrc.js` from 1800ms to 250ms. As an added bonus, plugins specified by path will also have their `require()` statement generated automatically when using `toString()`, saving the need for callers to manually do so using `__expression`. The plugin path is passed back to `toString()` separately, since it needs stringifying to ensure special characters are escaped (such as the backslashes in Windows-style paths) - and I'd prefer to avoid importing `javascript-stringify` outside of `toString()`.
|
@yyx990803 Hi :-) Is this something that |
|
Nice, this is great! |
eliperelman
approved these changes
Sep 12, 2018
|
@eliperelman would it be possible to release a new version? |
edmorley
added a commit
to neutrinojs/neutrino
that referenced
this pull request
Sep 14, 2018
webpack-chain 4.11.0's `.plugin('abc').use(...)` now supports being
passed the path to a plugin, instead of the plugin itself. See:
neutrinojs/webpack-chain#102
This means we can avoid the expensive `require()` of plugins in cases
where the plugin isn't used - such as when:
* running ESLint's CLI with a Neutrino-generated `.eslintrc.js`
* running tests with Jest/Mocha (which don't perform a webpack build)
* the plugin isn't needed for that `NODE_ENV` (eg `clean-webpack-plugin`
isn't used in development).
For example, this reduces `time node .eslintrc.js` for a React+AirBnb
project from 1700ms to 370ms - and for projects that use more of the
non-default core Neutrino presets, the improvement will be even more
noticeable.
As an added bonus, plugins specified by path also have their `require()`
statement generated automatically when using `toString()`, meaning
that the configuration output by `--inspect` no longer needs any
adjustments before it can be run.
ie this "just works" with the core presets:
```
$ echo "module.exports = $(yarn neutrino --inspect --mode production);" > exported-config.js
$ yarn webpack --config exported-config.js
```
The webpack-chain docs have also been synced with those from upstream.
Refs #239.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This allows the expensive
require()s to be skipped in cases where the plugin or webpack configuration won't end up being used. For example, using this feature in Neutrino reduces the overhead of dynamically generating.eslintrc.jsfrom 1800ms to 250ms.As an added bonus, plugins specified by path will also have their
require()statement generated automatically when usingtoString(), saving the need for callers to manually do so using__expression.The plugin path is passed back to
toString()separately, since it needs stringifying to ensure special characters are escaped (such as the backslashes in Windows-style paths) - and I'd prefer to avoid importingjavascript-stringifyoutside oftoString().