-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
HMR ignores public/publicPath/sockHost/sockPort/sockPath configs #2164
Comments
Why you use |
@evilebottnawi
It's exactly my case - in inline mode HMR guess URL from BTW I tried to explicitly specify |
I debugged it a bit and that what I found:
It seems like having two different options with the same name |
I think this is probably fixed in But the reference to Check for the comment at the top of the file:
See facebook/create-react-app#3814 for the rejected |
I have the same issue with webpack-dev-server 3.9.0. I have a proxy that redirects requests to WDS but it does not support proxying websockets. So I thought I could just change the sockHost & sockPort options to get the socket loaded directly from WDS. This is not working at all sadly… |
@qraynaud please create reproducible test repo, thanks |
Not sure how useful this information is, but hard coding |
I found out that it's possible to work around this issue by:
Here's a sample of 1.: proxy: {
'*': { target: 'https://127.0.0.1:8000', secure: false },
}, |
We do big refactor in webpack-dev-server v4, now you have NOTE, Anyway if you will faced with the issue again, feel free to open new issue, sorry for delay |
Hope this gets released soon in a beta version so more people can easily try it out |
@r4j4h we have plan to do rc release by next week. |
@snitin315 that's great to hear! thank you for giving me a timeline 🎉 I also have a wonder that I haven't seen mentioned, does Even if not, since it's under folder webpack_dev_server in worst case I imagine another proxy mapping could be made. But if I understand correctly, something would have to be done in a reverse proxy'd by path scenario, or else those calls will not find their way to the webpack dev server in those cases. |
Just wanted to report in the quickest way instead of creating a new issue, that after updating to the new version things largely work, much better than before, but there seems to still be a problem around some hot reloading after a file changes:
A file named as such |
Operating System: macOS 10.14.5
Node Version: 12.4.0
NPM Version: 6.9.0
webpack Version: 4.38.0
webpack-dev-server Version: 3.7.2
Browser: Google Chrome 75.0.3770.100
This is a bug
This is a modification request
Code
Repository with repro: https://github.com/maxlk/webpack-hmr-behind-proxy-issue/
A website is served by 3rd party HTTP server. For example it's served from origin
http://local.myhost.com
.JavaScript bundle is served by WDS and is loaded loaded from different origin, for example
http://localhost:8080
.Expected Behavior
HMR should load updates from WDS URL. It is provided in
public
andpublicPath
config options. It's also available insockHost
,sockPort
andsockPath
config options.Update's URL should be like
http://localhost:8080/5cc71fea9aecb707e3fc.hot-update.json
.Actual Behavior
HMR tries to load update from
window.location
(even withpathname
(?!)) instead of building the correct URL from config (<public><publicPath><update-hash>.hot-update.json
or<sockHost>:<sockPort>/<sockPath>/<update-hash>.hot-update.json
).Particularly in this example it tries to load update from
http://local.myhost.com/some/path/5cc71fea9aecb707e3fc.hot-update.json
.It causes 404 error, hot reload fails and full reload is triggered.
For Bugs; How can we reproduce the behavior?
git clone git@github.com:maxlk/webpack-hmr-behind-proxy-issue.git
cd webpack-hmr-behind-proxy-issue
npm install
npm start
http://localhost:9876/www/
in web browser.src/print.js
and save it.GET http://localhost:9876/www/5cc71fea9aecb707e3fc.hot-update.json 404 (Not Found)
error and full reload (instead of hot reload) will be triggered.The text was updated successfully, but these errors were encountered: