CLI documentation update from CI
CI User committed
Dec 10, 2021 at 02:27 UTC
f42b414cfc5b0bf37bd52b3310ae5bc8d00ad99b
2 files changed
+104
-1
cli/v8
+1
-1
@@ -1 +1 @@
1
-Subproject commit 4dbeb007d0d6350284c7b1edbf4d5b0030c67c66
1
+Subproject commit d8aac8448e983692cacb427e03f4688cd1b62e30
content/cli/v8/configuring-npm/package-json.md
+103
@@ -881,6 +881,109 @@ if (foo) {
881
Entries in `optionalDependencies` will override entries of the same name in
882
`dependencies`, so it's usually best to only put in one place.
883
884
+### overrides
885
+
886
+If you need to make specific changes to dependencies of your dependencies, for
887
+example replacing the version of a dependency with a known security issue,
888
+replacing an existing dependency with a fork, or making sure that the same
889
+version of a package is used everywhere, then you may add an override.
890
+
891
+Overrides provide a way to replace a package in your dependency tree with
892
+another version, or another package entirely. These changes can be scoped as
893
+specific or as vague as desired.
894
+
895
+To make sure the package `foo` is always installed as version `1.0.0` no matter
896
+what version your dependencies rely on:
897
+
898
+```json
899
+{
900
+ "overrides": {
901
+ "foo": "1.0.0"
902
+ }
903
+}
904
+```
905
+
906
+The above is a short hand notation, the full object form can be used to allow
907
+overriding a package itself as well as a child of the package. This will cause
908
+`foo` to always be `1.0.0` while also making `bar` at any depth beyond `foo`
909
+also `1.0.0`:
910
+
911
+```json
912
+{
913
+ "overrides": {
914
+ "foo": {
915
+ ".": "1.0.0",
916
+ "bar": "1.0.0"
917
+ }
918
+ }
919
+}
920
+```
921
+
922
+To only override `foo` to be `1.0.0` when it's a child (or grandchild, or great
923
+grandchild, etc) of the package `bar`:
924
+
925
+```json
926
+{
927
+ "overrides": {
928
+ "bar": {
929
+ "foo": "1.0.0"
930
+ }
931
+ }
932
+}
933
+```
934
+
935
+Keys can be nested to any arbitrary length. To override `foo` only when it's a
936
+child of `bar` and only when `bar` is a child of `baz`:
937
+
938
+```json
939
+{
940
+ "overrides": {
941
+ "baz": {
942
+ "bar": {
943
+ "foo": "1.0.0"
944
+ }
945
+ }
946
+ }
947
+}
948
+```
949
+
950
+The key of an override can also include a version, or range of versions.
951
+To override `foo` to `1.0.0`, but only when it's a child of `bar@2.0.0`:
952
+
953
+```json
954
+{
955
+ "overrides": {
956
+ "bar@2.0.0": {
957
+ "foo": "1.0.0"
958
+ }
959
+ }
960
+}
961
+```
962
+
963
+You may not set an override for a package that you directly depend on unless
964
+both the dependency and the override itself share the exact same spec. To make
965
+this limitation easier to deal with, overrides may also be defined as a
966
+reference to a spec for a direct dependency by prefixing the name of the
967
+package you wish the version to match with a `$`.
968
+
969
+```json
970
+{
971
+ "dependencies": {
972
+ "foo": "^1.0.0"
973
+ },
974
+ "overrides": {
975
+ // BAD, will throw an EOVERRIDE error
976
+ // "foo": "^2.0.0"
977
+ // GOOD, specs match so override is allowed
978
+ // "foo": "^1.0.0"
979
+ // BEST, the override is defined as a reference to the dependency
980
+ "foo": "$foo",
981
+ // the referenced package does not need to match the overridden one
982
+ "bar": "$foo"
983
+ }
984
+}
985
+```
986
+
987
### engines
988
989
You can specify the version of node that your stuff works on: