I have Vue project that has standard webpack configuration generated from the Vue CLI. This gives project directory structure such as:
public\
css\
images\
index.html
src\
tests\
package.json
etc...
So the default static assets directory is public\ in the root of the project dir. Now I want to specify another static directory (which will be located somewhere in the src\) such that content of these two dirs is merged on build. In case of file conflicts, the file from src\ should overwrite the one in public\.
How can I do this with webpack?
The reason I need this is because I want to make separate builds for different customer. Each customer will have it's own specific assets and components which I plan to put somewhere in src\. Eg:
public\ // shared static assets
src\
components\ // shared stuff for all customers
store\
...etc
customer1\ // customer1 specific stuff below this level
public\ // merge these with shared static assets and overwrite if necessary
components\
store\
index.js
customer2\ // customer2 specific stuff below this level
public\
components\
store\
index.js
So then when I run npm run build --customer=customer1 I want to get only shared + customer1 stuff in the bundle. I almost solved this for customer's components, store and other non-static stuff via webpack alias config and I am wondering how can I do it for static assets in the public directory?
That is not how Webpack works. When you compile your App, the first thing Webpack does is to scan your code and build a dependency tree. In reality, a dependency can be many things, but think of them as your "imported files".
The scan starts at your entry point, generally src/index.js and it proceeds recursively from there. What I want to be clear with this is that only "explicit" dependencies are bundled, anything else will be ignored. In other words, if you don't import something and have a specific loader for that, that asset will not be bundled.
So again, Webpack does not scan your src directory, but traverses your App from its entry point.
Also consider that with a good setup (like the one included with Create React App) almost every asset will be converted into a JS module and merged into chunks with a specific naming convention to allow cache invalidation. This is to say that there is little probability there will be name collisions.
Given your case, I would very, very, very, very highly recommend you to have a different repository for each different client. If you need to reuse components, author a library. If you need to reuse assets, optimize them and host them on a CDN. I would expect security, maintainability and scalability problems with your approach.
Finally, if you insist, one viable approach would be to have a custom plugin attached to those "static" directories inside your src directory (you can search around if there is already one available, if not, see custom plugins in Webpack documentation, it is not that straightforward though). That plugin would basically change the path of the imported file based on an environment variable or a passed option.
Please let me know if I am overlooking something, but I really think you should separate the projects, even if the "base" is the same.
As a final note: Your approach would must likely break any static analysis (Forget about TypeScript, Flow, JSDocs, IDE auto-completion and hinting, etc.). You would be also breaking modular programming paradigm. This especially applies to components. With other media assets like images there would be less constraints, but still encounter issues. How would your app run in dev mode? At best you'll encounter performance problems. You can break HMR (Hot Module Replacement), app tests... I'll stop here.