[TOOLING]: Better webpack configurations #7045
-
SummaryThread for discussing webpack configurations |
Beta Was this translation helpful? Give feedback.
Replies: 11 comments 1 reply
-
|
@unlikelyzero @ozyx I'm interested in your opinion of your production build. Do you need specific file endings/naming, or am I free to add minification and changes to the generated dist folder? |
Beta Was this translation helpful? Give feedback.
-
|
Also forgot to mention, but the welcoming vibes from you on this project is very chill! Thank you! 🇺🇸 |
Beta Was this translation helpful? Give feedback.
-
|
@evenstensberg interested to learn what all you can recommend. minification would be great. What sort of |
Beta Was this translation helpful? Give feedback.
-
|
@unlikelyzero In the first iteration, I'd like to generate a good dist structure that groups images, js, html etc into respective folders. In addition to that, enable minification as far as possible without breaking your development flow. The reason why I was curious about it, was that I ought to think that you use a simple prod configuration so that bug tracking is easier. In production you cant easily debug since the generated source map is of another type. Did that make sense? |
Beta Was this translation helpful? Give feedback.
-
|
Relative #6120 |
Beta Was this translation helpful? Give feedback.
-
|
@unlikelyzero How do you serve the OpenMCT application to consume? Do you have apache/nginx or do you just run webpack dev server? |
Beta Was this translation helpful? Give feedback.
-
|
https://github.com/scottbell/openmct-quickstart is our first attempt at publishing some of the best practices when using Apache @evenstensberg |
Beta Was this translation helpful? Give feedback.
-
|
@unlikelyzero okay. Reason for asking is, that if you either spin up a express server with openmct, you can achieve some good performance benchmarks. Atm openmct is bundled to one file that is imported by your consumers, and naturally the size of the application will take longer to load. |
Beta Was this translation helpful? Give feedback.
-
|
The goal is to run this collection of performance tests https://github.com/unlikelyzero/openmct-performance Against the OpenMCT-quickstart repo within 2 weeks. |
Beta Was this translation helpful? Give feedback.
-
|
I'm interested in the above also regarding webpack, etc. I have been able to serve our app built on top of the OpenMCT nuget package (ala the tutorial) and since our data sources are external to this, I was able to serve the app with just Apache and no node. (Someone tell me if I'm going to be missing some capability doing that...??) Anyway, that was copying the node_modules/openmct/dist folder to my Apache htdocs area. And I can webpack the app (after moving the script lines to imports in an index.js) and that works EXCEPT this line
I'm working on somehow getting this worked into the webpack output. So as I said, I'm interested in this topic. However it seems to have possibly died on the vine. Was there any progress made on this? |
Beta Was this translation helpful? Give feedback.
-
|
Hi again @evenstensberg ! We welcome your Webpack expertise and we are certainly open to any changes that will improve our build process. We are especially interested in anything that improves performance. We would like to retain the ability to generate builds with or without source maps for the reasons you mentioned. Often our "production" environments are really more formalized test environments where it's still necessary to debug issues in-situ so a compromise between exhaustive and performant source maps is preferred. We'll definitely take a look at cheap-eval-sourcemap as you suggested on #6120, thanks for the suggestion! To answer some of the questions that have been raised in this discussion, in production environments we simply host the built JavaScript, HTML, and CSS from a general purpose HTTP server like Apache or Nginx. We have more experience with Apache than Nginx. We only use webpack dev server for development purposes. The asset path is used for resolving the runtime location of various assets (CSS, images, shared worker code) that Open MCT needs to operate at run time. This is certainly something that could be set during build time. We use |
Beta Was this translation helpful? Give feedback.
-
|
If your goal is to optimize for distributions across libraries/frameworks there's a limited amount of optimizations that we can configure. But.. There's some research/draft projects that explore more agressive performance optimizations to the runtime code, such as Closure |
Beta Was this translation helpful? Give feedback.
Hi again @evenstensberg ! We welcome your Webpack expertise and we are certainly open to any changes that will improve our build process. We are especially interested in anything that improves performance. We would like to retain the ability to generate builds with or without source maps for the reasons you mentioned. Often our "production" environments are really more formalized test environments where it's still necessary to debug issues in-situ so a compromise between exhaustive and performant source maps is preferred. We'll definitely take a look at cheap-eval-sourcemap as you suggested on #6120, thanks for the suggestion!
To answer some of the questions that have been raised in this …