feat: plugin support#5650
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## next #5650 +/- ##
==========================================
+ Coverage 88.85% 89.08% +0.23%
==========================================
Files 13 13
Lines 5893 5999 +106
==========================================
+ Hits 5236 5344 +108
+ Misses 657 655 -2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
We should start it in webpack-dev-middleware, currently |
bjohansebas
force-pushed
the
plugin-support
branch
from
0d79407 to
8664549
Compare
bjohansebas
force-pushed
the
plugin-support
branch
from
d8084a7 to
9890a76
Compare
bjohansebas
force-pushed
the
plugin-support
branch
from
9890a76 to
616b803
Compare
bjohansebas
left a comment
bjohansebas
left a comment
There was a problem hiding this comment.
These changes should work without requiring any changes to webpack-cli yet. Once this is merged, we can work on a patch for webpack-cli to use the plugin support, but it is independent of changes to webpack-cli.
|
cc: @alexander-akait friendly ping for feedback |
|
Will look soon, I little bit busy, we should make the new major release the next week, I will help you to finish remains tasks |
|
@bjohansebas let's rebase |
bjohansebas
force-pushed
the
plugin-support
branch
2 times, most recently
from
1060a9c to
4591762
Compare
|
@bjohansebas can take a look at our failed tests, a lot of PRs without green, we need to resolve it, thanks |
bjohansebas
force-pushed
the
plugin-support
branch
from
bb3626c to
9912722
Compare
Those are just flaky tests, like before. You just need to rerun them and that's it. |
|
Looks like problem with lint here |
bjohansebas
force-pushed
the
plugin-support
branch
from
9912722 to
0102816
Compare
…ng in Server class
bjohansebas
force-pushed
the
plugin-support
branch
from
0102816 to
2d6d746
Compare
| // the user is not in control of the plugin lifecycle here, so we stay | ||
| // silent rather than logging a warning. | ||
| const isBuildMode = () => | ||
| childCompilers.every((child) => !child.watching && !child.options.watch); |
There was a problem hiding this comment.
Each compiler have watching when it is watching, no need to check on watch, at least I can see situation when watch will be true, but watching undefined
| if (seenFirstDone.has(childCompiler)) return; | ||
| seenFirstDone.add(childCompiler); | ||
| firstDoneCount++; | ||
| if (firstDoneCount < childCompilers.length) return; |
There was a problem hiding this comment.
Can you clarify when we need firstDoneCount?
| childCompiler.hooks.done.tapPromise(pluginName, () => | ||
| onChildDone(childCompiler), | ||
| ); | ||
| childCompiler.hooks.shutdown.tapPromise(pluginName, onChildShutdown); |
There was a problem hiding this comment.
Ideally we should have the same hooks for multi compiler, and so don't use for/of, but we can postpone it and improve later
| }; | ||
|
|
||
| for (const childCompiler of childCompilers) { | ||
| childCompiler.hooks.beforeCompile.tapPromise(pluginName, ensureSetup); |
There was a problem hiding this comment.
Can we avoid beforeCompile at all, it is unsafe in some cases, ideally we should use only done and shutdown
There was a problem hiding this comment.
I think we can done everything on done, also please add a test case what we really change outputFileSystem and use it, not webpack built-in the real fs
2 participants
Summary
What kind of change does this PR introduce?
Did you add tests for your changes?
Does this PR introduce a breaking change?
If relevant, what needs to be documented once your changes are merged or what have you already documented?