-
|
Some thoughts about Web Vitals led me to an experimental Webpack configuration, where compression-webpack-plugin generates compressed versions of static files (html, js, сss, svg, json...). I used the plugin without additional settings. As a result of compilation, pre-compressed versions of static files were added to the result. Tests of the compiled html pages did not reveal any errors. I deployed the result on the server and was surprised to find an error loading js files. The message in the console informed that the js file was not loaded from the link to the source code (!). I was very surprised and the first thing I did was recheck the Webpack configuration. The settings were correct - for production. Then I rechecked the compiled html pages. And I also did not find any errors. The link to the js file fully corresponded to the production configuration. But the error in the browser console pointed to a completely different link used in the source code of the web page. I was already at a complete loss when I unzipped the compressed copy of the page and found this damn link to the source code there. I spent some more time transforming the link in the source code of the pages, including the inline request, but it did not lead to anything. The links to JS files in compressed archives still point to the source code instead of the compiled files. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 2 replies
-
|
During the experiments, a scenario for another error was found. There are several html pages using the same app.js file. But if you change the script tag in one of the templates (it can be an async attribute or an inline request), then the compilation fails. It's not critical in my scenarios, but |
Beta Was this translation helpful? Give feedback.
-
|
@vralle |
Beta Was this translation helpful? Give feedback.
-
|
Hi, @webdiscus and Merry Christmas! I created an "issues" branch here |
Beta Was this translation helpful? Give feedback.
Hello @vralle,
Thank you!
Merry Christmas to you too!
Please, follow the issue #134.