Is your proposal related to a problem?
Currently, some Jest options can be overridden through Jest config in package.json, but the overrides are appended to the built-in config options. This complicates or totally disallows overrides for configuration options, that are sensitive to the order.
For example, the transform option in Jest lists an import path regular expression to the Jest transformer. The Map<ImportPathRegExp, Transformer> is iterated in Jest from the beginning, and the first transformer that matches the import path is used. Because the built-in transformers in CRA contain a very general import path regexp for practically all {Java,Type}Script files, it is impossible to specify a custom transformer for {Java,Type}Script files, because the built-in transformer is always listed before the custom transformer and the built-in transformer matches all {Java,Type}Script files. In this kind of situation, the specific configuration options have to go before the more general ones, but the CRA does not allow us to tweak the order of configuration options.
Describe the solution you'd like
Currently, for object types, the CRA simply spreads the custom config into the built-in, this allows to override via replacing e.g. when the custom config contains exactly the same key as built-in config, the custom will replace the built-in, this is apparently used for replacing the built-in Jest transformer with ts-jest and this stops working when the built-in config changes slightly (#9667).
A better option would be to spread the custom config before the built-in, this will provide more control to the users and the built-ins will act as a fallback. It is not simple as that, because then the custom option will be replaced by a later appended built-ins when the keys are equal. The sketched implementation would go like
config[key] = Object.assign({}, overrides[key], Object.assign({}, config[key], overrides[key]));The entries from overrides[key] are declared first, then the built-in from config[key] are appended but before, it is combined with overrides[key] again and this time the overrides[key] replaces built-in config[key] when the keys are equal.
I hit this problem with the transform property and I'm not sure if this behavior will fit all supported configuration options.
Is your proposal related to a problem?
Currently, some Jest options can be overridden through Jest config in
package.json, but the overrides are appended to the built-in config options. This complicates or totally disallows overrides for configuration options, that are sensitive to the order.For example, the
transformoption in Jest lists an import path regular expression to the Jest transformer. TheMap<ImportPathRegExp, Transformer>is iterated in Jest from the beginning, and the first transformer that matches the import path is used. Because the built-in transformers in CRA contain a very general import path regexp for practically all {Java,Type}Script files, it is impossible to specify a custom transformer for {Java,Type}Script files, because the built-in transformer is always listed before the custom transformer and the built-in transformer matches all {Java,Type}Script files. In this kind of situation, the specific configuration options have to go before the more general ones, but the CRA does not allow us to tweak the order of configuration options.Describe the solution you'd like
Currently, for object types, the CRA simply spreads the custom config into the built-in, this allows to override via replacing e.g. when the custom config contains exactly the same key as built-in config, the custom will replace the built-in, this is apparently used for replacing the built-in Jest transformer with
ts-jestand this stops working when the built-in config changes slightly (#9667).A better option would be to spread the custom config before the built-in, this will provide more control to the users and the built-ins will act as a fallback. It is not simple as that, because then the custom option will be replaced by a later appended built-ins when the keys are equal. The sketched implementation would go like
The entries from
overrides[key]are declared first, then the built-in fromconfig[key]are appended but before, it is combined withoverrides[key]again and this time theoverrides[key]replaces built-inconfig[key]when the keys are equal.I hit this problem with the
transformproperty and I'm not sure if this behavior will fit all supported configuration options.