fix($hmr): Target correct link tags when hot reloading. #24
Conversation
Update the logic for comparing link tags' URLs so that the correct pathname is matched against. #23
|
And here she is in action:
|
|
Excellent! Question: what's the browser support for Also, does this solve this issue: |
|
Fair question! Looks like support is solid except in IE: http://caniuse.com/#feat=url. For what it's worth I can't get HMR working at all in IE--- As written this will not fix #25, but if you want to go the |
If the Webpack publicPath contains "http:" or "https:", treat it as the base URL for newly-loaded assets. Otherwise, continue to use the current window's location. Fixes #25.
hotModuleReplacement.js
Outdated
| var origin = document.location.protocol + '//' + document.location.hostname + (document.location.port ? ':' + document.location.port: ''); | ||
| var newHref = origin + publicPath + outputFilename | ||
| var styleSheets = document.getElementsByTagName('link'); | ||
| var newHref = publicPath.match(/https?:/g) ? new URL(outputFilename, publicPath) : new URL(outputFilename, window.location); |
There was a problem hiding this comment.
is the publicPath lost in case it is relative?
new URL(outputFilename, window.location); => new URL(publicPath + outputFilename, window.location); ?
There was a problem hiding this comment.
Good catch! Wasn't necessary with my setup because publicPath was /, but I think you're right that if it's more involved it'd be dropped on the floor. Fix coming presently, thanks!
Previous code dropped publicPath on the floor when it was relative, which would have broken certain corner cases.
|
I like the URL route. As you mentioned, webpack-hot-middleware has issues with IE anyway, and polyfills are available: webpack-contrib/webpack-hot-middleware#11 Otherwise, excellent work! Thanks for this. |
|
De nada! Glad to give back. 💖 |
Update the logic for comparing link tags' URLs so that the correct pathname is matched against.
Fixes #23.