Closed prestomation closed 2 years ago
I forgot to add this comment in my first round review: there are bunch of ***.spec.js
files generated after I ran the tests. Did this happen on your end?
I forgot to add this comment in my first round review: there are bunch of
***.spec.js
files generated after I ran the tests. Did this happen on your end?
I think we should remove the output
field when importing the base webpack config into the test webpack config
Thanks for the tip on removing the output
from webpack config during test. I've added this.
I messed up something rebasing with origin, so some commits look duplicated. I will squash them on when merging.
Before we had an overcomplicated webpack setup. There were 3 webpack files + karma config per subpackage doing a bunch of inheritance
This caused a few problems:
The webpack builds were not aware of each other, so if you ran webpack in the babylon folder but changed something in core, you had to rebuild core.
The test target ran each subpackage test in sequence. You would have to scroll through the results to find the individual summary of each package.
It comes down to: We don't have a large enough of a monorepo to require many builds. We want multiple output packages, but multiple build processes are not helping us right now.
To fix, I have consolidated these. There is a single webpack build. There is still a 'test' that inherits from it, but only adds a few plugins needed to get the tests to run using three/babylon.
There is also a single karma config and all tests run together.
I removed a bunch of cruft from these, including a custom resolver that meant the code could 'only' run in webpack. I feel it's better to make things as vanilla as we can, no reason to depend on specific webpack features without a clear benefit.
I've also removed babel and any source map configuration, we can still tune thes but I'm not sure they are doing us any good either.
What's left:
Testing so far:
npm test works for most tests
npm build runs the single webpack build.
npm start
works and is able to serve the babylon examples. hotreload now works for code built by webpack. That is, open an example, change a piece of core or babylon code, and the code will rebuild and refresh the page. With Kris's PR, this will extend to the example app code itself(it is not built with webpack at the moment)Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.