I've noticed that many developers start using overrides in an unsafe style when reading the documentation.
There is no information in the documentation that you can specify a refinement of the package version for redefinition (there are only matchers for parent packages)
As a result, developers are starting to do something like this.
"overrides": {
"path-to-regexp": "0.1.13"
},
In this way, they reimplement all versions of packages in the dependency tree, which is fundamentally unsafe.
path-to-regexp@0.1.12 -> 0.1.13
path-to-regexp@8.3.0 -> 0.1.13
path-to-regexp@8.4.0 -> 0.1.13
path-to-regexp@2.4.0 -> 0.1.13
NPM has support matchers for specific package (without parent matcher).
"overrides": {
"path-to-regexp@0.1.x": "0.1.13",
"path-to-regexp@8.x.x": "8.4.0"
},
But I did not find this mention in the documentation. I see via docs only that style:
"overrides": {
"path-to-regexp@0.1.x": {
".": "0.1.13"
}
"path-to-regexp@8.x.x": {
".": "8.4.0"
}
},
Related links:
I've noticed that many developers start using overrides in an unsafe style when reading the documentation.
There is no information in the documentation that you can specify a refinement of the package version for redefinition (there are only matchers for parent packages)
As a result, developers are starting to do something like this.
In this way, they reimplement all versions of packages in the dependency tree, which is fundamentally unsafe.
NPM has support matchers for specific package (without parent matcher).
But I did not find this mention in the documentation. I see via docs only that style:
Related links: