expose source-map-support and support additional handlers #8930
Description
🚀 Feature Proposal
There is currently no clear way to add a source-map-support handler.
If any tested code actually calls require('source-map-support').install() stack traces for files transformed by Jest break.
source-map-support keeps an array of handlers, but somehow when setting it in test code, the original Jest handler is removed. Ideally these should coexist and share.
Motivation
Without this support, it makes testing code transforms difficult. It's a choice between incorrect stack traces in Jest environments, or correct stack traces for the tested code that handles its own source-maps and incorrect and broken stack traces for all other tests.
Example
The best solution would be to not use runtime.requireInternalModule() for source-map-support. Looking through the 300 something files that were also marked as internal modules, most are Jest-specific utility functions that do not maintain state or babel plugins so it makes sense to isolate them. In this case however, requiring source-map-support normally would fix a lot of issues.
As an experiment, I found that adding const isInternalModule = to !== 'source-map-support' inside the requireInternalModule() definition fixes all these issues I listed above.
The issue is that if it marked as internal, the module when called by test code has no clue that it has already been installed in the environment. Therefore, it overrides the Jest implementation. By not marking it as internal, the Jest implementation would actually stay intact as calling require('source-map-support').install() will simply push an additional handler to the array in that case.
This is the approach I would recommend.
Earlier thoughts and alternative approaches:
- Add a callback that allows the user to manipulate the source-map-support handlers and install an additional one after Jest installs its internal handler.
- Export the installer so tests could call e.g.
installDefaultJestSourceMapSupport()immediately after installing a user handler. - Transparently recognize calls to
require('source-map-support').install()and ensure that the Jest default handler cannot be removed.
Pitch
Why does this feature belong in the Jest core platform?
It is near impossible to get this to work without support from Jest. Jest doesn't like to share source-map-support which can cause confusing stack traces if the tested code actually needs to use source-map-support outside of the Jest environment. The fallback handler provided by source-map-support is not sufficient because it reads the source TSX files expecting to find a source-map comment there.