-
-
Notifications
You must be signed in to change notification settings - Fork 116
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
mergeWithRules and shortcuts (loaders
and use
)
#167
Comments
As I mentioned earlier, webpack-merge doesn't know anything about webpack configuration structure so it cannot do any sort of association between different properties that mean the same thing. It's a bit unfortunate webpack's configuration scheme is so flexible and often there are many ways to achieve exactly the same result. I had "smart" merging in place in an earlier version that did something along this but in the end it was a nightmare to maintain and in the end the different cases were too much to handle so I went with a simpler design that gives more control (essentially the new merge with rules feature).
What would be the expected result in this case? As I mentioned above, there's no logic within webpack-merge to deal with the discrepancies within webpack configuration. Now that I think of it, there might be a nice way to handle the problem in the user space by normalizing the configuration. What I mean is that you could have a conversion function Regarding the Does that sound like a plan? |
@bebraw Thanks for the swift response! I understand the generic nature of |
There's no way within the function. Patching webpack configuration feels like a too specific task for it.
I think it's looking for the It's a good case for me to catch. |
As a matter of fact if I change the const conf1 = {
module: {
rules:[
{
"test": "/\\.scss$|\\.sass$/",
"use": [
{
"loader": "sass-loader",
"options": {
"sourceMap": true,
"sassOptions": {
"precision": 8,
"outputStyle": "expanded"
}
}
}
]
}
]
}
};
const conf2 = {
module: {
rules:[
{
"test": "/\\.scss$|\\.sass$/",
"exclude": [
"/node_modules/",
"/v1/"
],
"use": [
{
"loader": "sass-resources-loader",
"options": {
"resources": [
"src/styles/includes.scss"
]
}
}
]
}
]
}
};
const mergeRules = {
module: {
rules: {
test: CustomizeRule.Match,
use: {
loader: CustomizeRule.Match,
options: CustomizeRule.Merge,
},
},
},
}
expect(mergeWithRules(mergeRules)(conf1, conf2)).toBeTruthy(); If in addition I change the merge rules to the following, the test will pass: const mergeRules = {
module: {
rules: {
test: CustomizeRule.Match,
use: CustomizeRule.Append
},
},
} Seems like a bug to me, am I wrong? |
@just-jeb Are you using |
The problem here is that there is a partial match. I'm not even sure what's the expected behavior in this case... |
Likely for a partial match, it shouldn't do anything as that's how it's defined to work. It's a good question if it should throw then or do something else. |
What I mean is that maybe one good option for non-matches would be to use the default merge behavior. |
Which is
|
Yup, it would append as a new rule.
I am not sure how to support the partial match case. It feels like a new operator. There should be a declarative way to define that as partial matches won't likely make sense as a default behavior due to how matching is defined and altering that would be a breaking change. |
Breaking change is not a big deal if you release a new major version 😄 In particular this one works: const conf1 = {
module: {
rules:[
{
"test": "/\\.scss$|\\.sass$/",
"use": [
{
"loader": "sass-loader",
"options": {
"sourceMap": true
}
}
]
}
]
}
};
const conf2 = {
module: {
rules:[
{
"test": "/\\.scss$|\\.sass$/",
"use": [
{
"loader": "sass-loader",
"options": {
"sassOptions": {
"precision": 8,
"outputStyle": "expanded"
}
}
},
{
"loader": "sass-resources-loader",
"options": {
"resources": [
"src/styles/includes.scss"
]
}
}
]
}
]
}
};
const expected = {
"module": {
"rules": [
{
"test": "/\\.scss$|\\.sass$/",
"use": [
{
"loader": "sass-loader",
"options": {
"sourceMap": true,
"sassOptions": {
"precision": 8,
"outputStyle": "expanded"
}
}
},
{
"loader": "sass-resources-loader",
"options": {
"resources": [
"src/styles/includes.scss"
]
}
}
]
}
]
}
} Note that the first configuration doesn't have However, the moment I remove const conf1 = {
module: {
rules:[
{
"test": "/\\.scss$|\\.sass$/",
"use": [
{
"loader": "sass-loader",
"options": {
"sourceMap": true
}
}
]
}
]
}
};
const conf2 = {
module: {
rules:[
{
"test": "/\\.scss$|\\.sass$/",
"use": [
{
"loader": "sass-resources-loader",
"options": {
"resources": [
"src/styles/includes.scss"
]
}
}
]
}
]
}
};
const expected = {
"module": {
"rules": [
{
"test": "/\\.scss$|\\.sass$/",
"use": [
{
"loader": "sass-loader",
"options": {
"sourceMap": true
}
},
{
"loader": "sass-resources-loader",
"options": {
"resources": [
"src/styles/includes.scss"
]
}
}
]
}
]
}
} I wouldn't expect that, I'd expect it to work just like the first example - if certain field doesn't exist then it's "merged" vacuously Both examples use this rule set: const mergeRules = {
module: {
rules: {
test: CustomizeRule.Match,
use: {
loader: CustomizeRule.Match,
options: CustomizeRule.Merge,
},
},
},
} So if one day I had to merge the configs like in first example, and the day after I didn't need the modification of |
Yeah, that's a good example I can use for a test. It definitely should fall back to a default merge if rules don't match. |
Do you think you'd be able to provide a fix soon? |
I will give it a quick go. If it doesn't require a big rewrite, then I can publish the fix soon but if it requires an architectural change, then it's going to be way harder. |
Two questions:
loaders
withuse
usingmergeWithRules
. Is it even possible? Any alternative?TypeError: Cannot read property 'options' of undefined
.I'm not sure about that, but I wouldn't expect it to fail. WDYT?
The text was updated successfully, but these errors were encountered: