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
ProgressPlugin: support progress by entry points #8279
Conversation
For maintainers only:
|
lib/Compilation.js
Outdated
@@ -1041,6 +1050,8 @@ class Compilation extends Tapable { | |||
* @returns {void} returns | |||
*/ | |||
addEntry(context, entry, name, callback) { | |||
this.hooks.addEntry.call(entry); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rename to buildEntry
and also pass name
as arguments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
addEntry
is not the same that buildEntry
addEntry
will be called when adding an entry. This need to calculate total entries
buildEntry
will be called when the module for an entry will be built
Or what do you mean? :)
lib/ProgressPlugin.js
Outdated
`${doneModules}/${moduleCount} modules`, | ||
0.1 + (doneModules / Math.max(lastCount, count)) * 0.6, | ||
`building ${mode}`, | ||
`${doneModules}/${count} ${mode}`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be much more useful if the handler took raw data (as an object or arguments in a particular order), rather than pre-made strings. E.g. in my implementation of a progress bar using the ProgressPlugin I have to resort to regexps/splits to re-parse the data out of the strings in order to be able to position them:
If instead we provided a default handler that makes these strings above, we can get the same behavior, and still give greater flexibility to consumers, alternative handlers.
I would imagine handler being most flexible e.g. when called like this:
handler({compilerIndex, currentStage, doneModules, activeModules, lastModulesCount, moduleCount, count, mode})
And some of those parameters would obviously be undefined
in certain stages (which is fine). By stage I mean the hook currently being executed, or compilation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
…webpack into support-entry-progress
The minimum test ratio has been reached. Thanks! |
@sokra any comments here? 😊 |
I'll finish it soon |
refactor activeModules to Set for performance reasons
Thank you for your pull request! The most important CI builds succeeded, we’ll review the pull request soon. |
Thanks |
@sokra Seems like it's broken by this change |
Fixed in #8335 |
closes #8088
What kind of change does this PR introduce?
mode
options)magic
number (only for progress by modules)Did you add tests for your changes?
I have no idea which tests can test a building progress...
Does this PR introduce a breaking change?
no
What needs to be documented once your changes are merged?
about new options