RFC: Dangerously Override Jest Config

[Jye Nicolson]

RFC: Dangerously Override Jest Config

Summary

Specify overrides to jest config in sku.config.js

Motivation

Currently sku's jest config hardcodes a pattern for mapping modules to identity-obj-proxy. Since this is the most convenient way to mock modules for jest tests, testing scripts that import anything outside that hardcoded pattern is more awkward with sku than it would be without.

Allowing selective overrides of jest config covers this more pressing use case, and any others that may arise, without requiring premature development of a more explicit jest configuration API.

Detailed design

If a dangerouslyOverrideJestConfig property is present on the first build in sku.config.js, it will be spread onto the existing Jest config object before being passed to jest during sku test`.

We use the first build because in most cases there will be only one build, and in a monorepo situation we have no clear way of dealing with multiple dangerouslyOverrideJestConfig objects. sku currently has no way to set global config affecting all builds.

How We Teach This

Since this is in the dangerouslyDoSomething genre, we don't need to document or teach it. We can make consumers aware of it if/when they come for help with jest mocking.

Usage (or lack thereof) of this option will guide us on development of a more specific API for configuring jest; teaching that would be heavily informed by any lessons we learn from this capability.

Drawbacks

Apart from the obvious dangers of dangerouslyOverrideJestConfig, that config is passed in from outside sku; resolving to anything internal to sku will be difficult and require deep sku knowledge.

Taking the first build's config only avoids the problem of build vs global config, but may be confusing for monorepo consumers (it would at least be harmless if the same config was set multiple times).

Improvements made to jest config would be missed by consumers overriding them.

Alternatives

Two obvious alternatives present themselves:

1. Force consumers to mock imports to jest tests by other means, don't touch jest config until forced by at least one more use case.

2. Make a specific jest configuration API now, starting with allowing a string or array of strings to be passed in config for identity-obj-proxy

[Mark Dalgleish]

For consistency, I think it should be called dangerouslySetJestConfig, but otherwise I think this is definitely a useful escape hatch to have 👍

[Jye Nicolson]

#61

(with dangerouslySetJestConfig as requested!)