chore: transformers must return objects, not strings

[SimenB]

Summary

Follow-up to #10753 with more scheduled breaking changes in the transformer.

Test plan

Green CI

[ahnpnl]

oops !!!! I just made a transformer for jest-preset-angular to return a string 😁

[SimenB]

Yeah, I'm not 100% convinced we should do this. There's not that much code saved - we can normalize where we call process and be done with it. It's useful for transforms even though - if they have a source map - it'd be better if they returned it as separate objects

[SimenB]

@thymikee @jeysal thoughts?

[thymikee]

I'd keep the normalization for one more version and output a deprecation warning. Should give maintainers some time to migrate.

[SimenB]

Normalization is const transformed = typeof output === string ? { code: output } : output, so it's not that much code. We could still cleanup internal types so it only happens in one place

[jeysal]

Yeah TBH 'overloading' the return with string and object doesn't seem bad to me as a permanent solution if we treat it like config by normalizing straight away when we received the result. Unless we want to encourage people in general to have their transformers add some of the optional properties because it improves user experience? In that case an object where people will wonder what other properties they could add would be a good nudge.

[SimenB]

Unless we want to encourage people in general to have their transformers add some of the optional properties because it improves user experience? In that case an object where people will wonder what other properties they could add would be a good nudge

One obvious one is module format (#9860 (comment)) and it is very much preferable if people return source maps if they have them as json already instead of us extracting them (via a regexp) from the returned string.

Printing some warnings if either map is missing (perhaps they should explicitly say null) or moduleFormat (so they explicitly say CJS) might make sense. Dunno?

[jeysal]

Yeah in that case a string would always generate a warning anyway so we might as well use that as the deprecation message 'transformers need to specify a moduleFormat from Jest X on, return an object with code and moduleFormat' and go with the gradual migration approach

[ahnpnl]

just an idea related to this type of breaking change: perhaps Jest can start pushing out pre-release major versions as well as update CHANGELOG for pre-release major versions. Also, taking into account of pre-release major versions as a part of release process. I see most of big repos do that so I don't see any reasons not doing it for Jest.

That will give users more possibilities to test changes, adopt anything possible etc.. which is especially useful when coming to major versions with breaking changes. For minor/patch versions, that is not needed.

[SimenB]

27 will be quite breaking across the board (API wise and changing default, plus underlying implementations), so we'll definitely be pushing out pre-releases for this one 👍 Will start this week or next (a bit delayed due to various nugs that needed patches, but I think we're good to go now)

[ahnpnl]

Do we expect to land this for 27 ?

[SimenB]

I don't think we need to do this one, did #10823 as solution for "this file is ESM"

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.