Skip to content
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

fix(utils): addEntries fix #2723

Closed
wants to merge 18 commits into from
Closed

Conversation

knagaitsev
Copy link
Collaborator

@knagaitsev knagaitsev commented Aug 28, 2020

  • This is a bugfix
  • This is a feature
  • This is a code refactor
  • This is a test update
  • This is a docs update
  • This is a metadata update

For Bugs and Features; did you add new tests?

Yes

Motivation / Use-Case

This is a PR for: #2692 (comment)

Basically, we should not be re-injecting entries that the user provided, we should only inject webpack-dev-server entries, as the webpack compiler should already handle the user's entries

Breaking Changes

  • The addEntries util API has changed to take a compiler argument

Additional Info

@knagaitsev knagaitsev changed the base branch from master to v4 August 28, 2020 01:16
@codecov
Copy link

codecov bot commented Aug 28, 2020

Codecov Report

Merging #2723 (dd66b7c) into v4 (6f5d0b6) will decrease coverage by 0.19%.
The diff coverage is 97.36%.

Impacted file tree graph

@@            Coverage Diff             @@
##               v4    #2723      +/-   ##
==========================================
- Coverage   93.04%   92.85%   -0.20%     
==========================================
  Files          39       39              
  Lines        1309     1330      +21     
  Branches      349      357       +8     
==========================================
+ Hits         1218     1235      +17     
- Misses         87       91       +4     
  Partials        4        4              
Impacted Files Coverage Δ
lib/utils/addEntries.js 98.75% <97.29%> (-1.25%) ⬇️
lib/utils/updateCompiler.js 100.00% <100.00%> (ø)
lib/utils/status.js 80.00% <0.00%> (-8.89%) ⬇️
lib/Server.js 96.08% <0.00%> (-0.25%) ⬇️
lib/utils/routes.js 98.14% <0.00%> (-0.07%) ⬇️
client-src/default/overlay.js 97.01% <0.00%> (-0.05%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6f5d0b6...572767e. Read the comment docs.

compiler.hooks.make.tapAsync(
{
name: 'webpack-dev-server',
stage: -100,
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@evilebottnawi @sokra I've added the tapAsync method here, but the issue I've found now is that something like this where multiple Servers are attached to a compiler no longer works:

const compiler = webpack(config);
const server1 = new Server(compiler, options1);
const server2 = new Server(compiler, options2);

as it results in something like Error: Conflicting entry option static = [object Object] vs [object Object]

This worked before, as there were tests that did this which are now broken. (These tests would usually close the old server before a new one was attached)

Should we go about this by making multiple servers on one compiler discouraged, or maybe a hacky method of disabling the old hook taps like in webpack/tapable#109 after the server is closed?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Or I could also try to prevent duplicate entries by looking at the compilation globalEntry object.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I added the hacky method for disabling old hook taps, but haven't added tests for it yet

Copy link
Member

Choose a reason for hiding this comment

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

@Loonride I think we should prevent duplicate, in theory we can have property on compiler to achieve this, we use same logic here https://github.com/webpack/webpack-dev-middleware/blob/master/src/utils/setupWriteToDisk.js#L9 (but it only for webpack@4)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@evilebottnawi That is a good idea, do you think I should remove my closeCallback method and replace it with setting something like compiler.hasWebpackDevServerMakeCallback = true?

Copy link
Member

Choose a reason for hiding this comment

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

I think it is more clean hack 😄

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@evilebottnawi I agree it is more clean, but one issue I now see is that if the user does:

const compiler = webpack(config);
const server1 = new Server(compiler, options1);
server1.close(() => {
  const server2 = new Server(compiler, options2);
});

If the options2 object results in a new set of entries, that will not be reflected in the compilation, since the old make callback would still be used.

@knagaitsev knagaitsev closed this Sep 7, 2020
@knagaitsev knagaitsev reopened this Sep 7, 2020
@alexander-akait
Copy link
Member

@Loonride ready for review?

@knagaitsev
Copy link
Collaborator Author

@evilebottnawi Almost, but 2 things

  1. Need advice on the above problem
  2. This is appearing in CI for webpack@next:
<e> [webpack-dev-middleware] TypeError: done is not a function
<e>     at ready (/home/runner/work/webpack-dev-server/webpack-dev-server/test/helpers/test-server.js:51:7)
<e>     at Hook.eval [as callAsync] (eval at create (/home/runner/work/webpack-dev-server/webpack-dev-server/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:27:1)
<e>     at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (/home/runner/work/webpack-dev-server/webpack-dev-server/node_modules/webpack/node_modules/tapable/lib/Hook.js:18:14)

@alexander-akait
Copy link
Member

@Loonride I think related webpack/webpack-dev-middleware#682, maybe you can provide example of configuration?

@knagaitsev
Copy link
Collaborator Author

It looks like the issue is here:

await testServer.startAwaitingCompilation(config, testOptions);

lib/Server.js Outdated
@@ -50,7 +50,7 @@ class Server {
this.wsHeartbeatInterval = 30000;

normalizeOptions(this.compiler, this.options);
updateCompiler(this.compiler, this.options);
this._closeCallback = updateCompiler(this.compiler, this.options);
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

do you agree with this naming since it is supposed to be an internal property?

Copy link
Member

Choose a reason for hiding this comment

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

Yes 👍

@knagaitsev
Copy link
Collaborator Author

@evilebottnawi Ready for review

@knagaitsev knagaitsev changed the title WIP: addEntries fix fix(utils): addEntries fix Sep 7, 2020
Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

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

I think after release webpack-dev-server@4 we should focus on extracting hot and client stuff from webpack-dev-server to separate middleware (we already have webpack-hot-middlware and webpack-client-middleware, we need deprecate them too) and use hooks for modify compiler/compilation options, also after this we can refactor webpack-dev-server to plugin, what do you think?

@hiroppy
Copy link
Member

hiroppy commented Sep 8, 2020

we should focus on extracting hot and client stuff from webpack-dev-server to separate middleware (we already have webpack-hot-middlware and webpack-client-middleware, we need deprecate them too)

Extracting is sounds good to me, but why do you want to deprecate them? You mean creating new libs...?

@alexander-akait
Copy link
Member

@hiroppy

Extracting is sounds good to me, but why do you want to deprecate them?

Because they do the same, only in a dirty way, I think it will be easier for us to union all into the one project, it will be easier to maintain and fix

You mean creating new libs...?

Yes, new, just maybe take name, webpack-hot-middleware sounds good

// this invalidates old make callbacks
compiler.webpackDevServerMakeCallbackCount += 1;
} else {
compiler.webpackDevServerMakeCallbackCount = 1;
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

My idea was to make a counter for callbacks, so that only the most recent callback will be used, fixing the problem I mentioned. Let me know if this seems too hacky.

@ylemkimon
Copy link
Contributor

@Loonride Would you mind if I take this PR?

@alexander-akait
Copy link
Member

alexander-akait commented Nov 17, 2020

@ylemkimon I think you can resent this PR, based on @Loonride activity, @Loonride is not available now

if you resent this fix, I will be very thankful

ylemkimon added a commit to ylemkimon/webpack-dev-server that referenced this pull request Nov 17, 2020
Cherry-picked from webpack#2723.

Co-authored-by: Loonride <knagaitsev1@gmail.com>
@alexander-akait alexander-akait deleted the branch webpack:v4 November 27, 2020 15:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants