-
-
Notifications
You must be signed in to change notification settings - Fork 118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to replace smart function when a specific loader in a chain needs to be overriden? #149
Comments
I think this one is related to #146. I have a potential proposal at #146 (comment) . Can you check and let me know if that would cover this case as well? In you case, another option would be to do a composition like this:
I explain the composition approaches here. I believe in your case it may be better to move the |
Would mergeArrays allow this code example? I assume sophisticated merge of loaders in rules is a common need. Maybe not something everybody should make on their own.
|
@TorRanfelt That's exactly what I was thinking about at #146 (comment) . I could provide a couple of building blocks like in the code example at my comment. Here's the code for reference: mergeArrays(
'test',
(a, b) => ({
...merge(a, b),
use: mergeArrays('use', merge)
})
)(a, b) |
I read your comment, but I was unsure how it would work in its entirety. Hence my example in order to verify that I had understood what you meant. - Your example is much simpler. The strategy can be simplified to this when using "..." and the fact that a rule-object only have one array ('loaders'):
Is this correct? |
@TorRanfelt With my proposed API and your problem, I think it would fall into 1. Check against Based on that, I imagine it would look like this: mergeArrays(
'test',
(a, b) => ({
...merge(a, b),
// Now the last with the same loader name would override completely.
// I think mergeArrays should give enough flexibility to be able to customize more.
loaders: unique('loaders', 'loader')(a, b)
})
)(a, b) Apart from the The key to this work is to find good building blocks for the API so we can both match and merge within a match and I imagine the final API will go to this direction. What you had in your code example would likely work as an API but it would be nice to find something that's concise and somehow readable. |
@bebraw Maybe an API that allows the following:
|
@TorRanfelt Yeah, that looks good. I'll try to implement something along those lines as doing this the right way should solve a couple of issues at once. |
@TorRanfelt I played around with the implementation. Here's the proposed API: #146 (comment) . mergeWithCustomize({
customizeArray: customizeArray({
"module.rules[test].loaders": CustomizeRule.Replace
})
}) It's going to need a small parser (parser generator even?) but I can map it from the selector syntax to code. |
I started implementing the chaining based API. I realized below is even more straight-forward: mergeWithCustomize({
customizeArray: customizeArray({
module: {
rules: {
test: CustomizeRule.Match,
loaders: CustomizeRule.Replace
}
}
})
}) This form has the added benefit of flexibility within a match and it seems easier to implement as well. |
I have a solution at #150. Can you check and comment? Thanks! |
@bebraw |
@TorRanfelt Ok, great to hear you like the API. I was thinking maybe it should replace the current The only problematic part I can see with the design is that given webpack configuration is polymorphic (esp. for loaders), it's not going to work for configurations that mean the same but have different structure in them. There isn't much I can do about that, though. The upcoming setup is close to as good as I can make it. 😄 |
@bebraw I don't think that's a problem. It's a limitation that is easy to understand, and it should be easy to keep the structure identical wherever a merge is needed (personally I think a consistent structure is the way to go anyway). Offering only merge of configurations on a syntactical level and not a semantic level is a sane scope constraint. The semantic level would yield negligible and frankly unnecessary gains while the work would be huge, error-prone and would require changes as webpack's semantics changes. |
Ok, makes sense. 👍 There's one corner case I have to tackle. After that the PR is good to merge. |
You should be able to do this type of merge in |
The following works in webpack-merge 4.2.2, but the smart function has been removed.
What I want is to override the configuration of the css-loader.
The text was updated successfully, but these errors were encountered: