This is a simplified scenario that I think other people can relate to, and has the following properties:
- 2 React projects with a shared components repo,
shared-repohas its own dependencies on modules exclusive to the other 2 projects.
- All React projects use ES6 and ES7 syntax. We use
- We run with code with
babel-nodethat programmatically start
It seems that the most effective way to have good development speed would be something like:
- The main repos and
shared-reposhould be compiled with babel, the others modules should just be imported without compiling.
- When code is ready to be released we can use tags for the
shared-repoand the main repo.
To me this scenario seems a simple one. If the assumption is that
node_modules are compiled to ES5, ideally I would have like to just say in one line "use babel-loader for
shared-repo but for no other dependencies".
When we were trying to implement this kind of workflow, it took a few days of trial and error. Most of the information we used to implement the solution was found in small parts of github issues. Our current webpack.config code for this setup takes up many lines, and even though it now works, we are unsure if it is overly-complicated or has undesired effects.
We think there are a number of sticking points. Firstly,
externals interact with each others in as pipeline that we could not find documented to any large degree. The documentation provided seems to take these settings one-by-one, and often does not include examples of more complicated setups.
Secondly, we found the documentation very unclear for https://webpack.github.io/docs/resolving.html and https://webpack.github.io/docs/library-and-externals.html From reading issues on github and other resources it seems like other users of webpack are also confused.
A few things we would love to have covered in more detail:
- How paths are resolved and in which order
- How to make simple import works without using relative syntax (
import mod from 'shared-repo'vs
import mod from '../../../../ shared-repo).
- How inclusions and exclusions work for loaders (for our project that means what files are being compiled by
babel-loaderand what is not )
- How does a
.babelrcfile in dependencies work when that dependency is being compiled by babel from another project (i.e. how can this file be ignored, for instance with with
- What needs to be an absolute paths and what need to be a relative path (aka
path.resolve) to make
npm linkwork with not only loaders, but also plugins.
First, I would like to understand what is the ideal solution for this scenario
Second, we think that the webpack community would benefit from a bit better documentation of the above list.
Is https://github.com/webpack/extract-text-webpack-plugin going to be improved? It seems pretty slow. We used that to compile
.sass files. We do not use CSS modules. Building styles was taking up to 40 seconds. We ended up moving
.sass compilation to
I use Figwheel a lot in my personal projects, it's like Webpack, but it appears that they have some difference. In Figwheel code is replaced directly and I don't have to handle the propagation. Amok is more like Figwheel and it just patches code at runtime. I mean it sounds they(Figwheel, Amok) are superior that we don't need to configure very much to make HMR work. Will Webpack update the HMR in the future?
I had struggle using webpack with applications that are not SPA. The best example I can mention is github.com. It consists of many small SPAish applications. What strategy I have to follow to use webpack when developing these kind of applications? (multiple bundles?...)