Skip to content

v4: client web socket port incorrect if using findPort instead of hard-coded port. #2873

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

Closed
1 of 2 tasks
jolyndenning opened this issue Nov 28, 2020 · 5 comments · Fixed by webpack/webpack-cli#2147
Closed
1 of 2 tasks

Comments

@jolyndenning
Copy link

jolyndenning commented Nov 28, 2020

  • Operating System: osx

  • Node Version: 14.15.0

  • NPM Version: 6.14.8

  • webpack Version: 5.8.0

  • webpack-dev-server Version: 4.0.0-beta.0

  • Browser: Chrome

  • This is a bug

  • This is a modification request

Code

When the port is left unspecified (both in CLI args and in webpack config), webpack-dev-server finds a port, defaulting to 8080 when possible. However, the webpack-dev-server client code is not aware of which port was chosen, and the resource query for setting up the web socket is unaware of that port. This causes the webpack-dev-server client code to attempt to connect to the wrong port when a bundle is loaded cross origin.

https://github.com/joeldenning/wds-port-bug

Expected Behavior

webpack-dev-server client code should set up the web socket connection on the port found by webpack-dev-server's findPort function.

Actual Behavior

webpack-dev-server client code defaults to establishing a web socket connection on the port of the origin server, instead of the port of the webpack-dev-server.

Note that in webpack-dev-server@3, this worked.

For Bugs; How can we reproduce the behavior?

https://github.com/joeldenning/wds-port-bug

For Features; What is the motivation and/or use-case for the feature?

@jolyndenning
Copy link
Author

jolyndenning commented Nov 28, 2020

I've looked into the code for this to see if I could put together a fix. Here are the relevant lines I found:

const port =
options.client && options.client.port
? `&port=${options.client.port}`
: '';

Ideally, I think it should be something like the following, although it does not work since the await isn't the right implementation approach here:

const port =`&port=${await findPort(options.client && options.client.port)}`

Like I said above, the code above doesn't work since apply() is not async and the code should set up the compilation hooks synchronously. I am happy to explore a fix for this further, if maintainers agree that this should be fixed.

@ylemkimon
Copy link
Contributor

ylemkimon commented Nov 28, 2020

Currently, it uses the location's port as the socket port, by default. Would this be undesirable? In the reproduction repo, I see you're accessing webpack bundle via another server (cross origin). What would be the use case?

@jolyndenning
Copy link
Author

Many microfrontend development workflows involve incorporating multiple webpack bundles into the same page, which often involves multiple webpack dev servers with code being loaded in the same page. Systemjs is often used to load the code, using webpack's libraryTarget system. I maintain single-spa, which is the most popular microfrontends solution, and it does this. See more at https://single-spa.js.org/docs/recommended-setup#local-development and https://github.com/joeldenning/import-map-overrides for more detail.

@jolyndenning
Copy link
Author

I've narrowed this down to the changes in webpack-dev-server@4 within the createDomain.js file. I'll send in a pull request with a fix soon.

@jolyndenning
Copy link
Author

The issue turned out to be deeper than just the changes to createDomain.js. The fix requires changes to webpack-cli and is more related to webpack serve than to webpack-dev-server@4. I've created webpack/webpack-cli#2147 which fixes it.

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 a pull request may close this issue.

2 participants