moduleDetection: auto makes cjs/cts files parse as modules, and ... #49268
Conversation
…sets moduleDetection: force
typescript-bot
added
Author: Team
For Milestone Bug
|
Does @DanielRosenwasser want @typescript-bot cherrypick this into release-4.7 ? |
|
Heya @weswigham, I've started to run the task to cherry-pick this into |
|
Hey @weswigham, I've opened #49276 for you. |
Component commits: 5d13ab2 moduleDetection: auto makes cjs files parse as modules, module: node sets moduleDetection: force
|
Today, if a user has sloppy-mode CJS files, they can use Does that escape hatch still work after this change? Should we have a baseline test to check this case? (I'm not sure how much to care about this scenario - mostly I'm just checking that any changes here are intentional). |
| // @allowJs: true | ||
| // @outDir: ./out | ||
| // @moduleDetection: auto | ||
| // @filename: foo.cjs |
There was a problem hiding this comment.
Does this also need change to isExternalOrCommonJsModule i think during incremental buildInfo doesnt mark bar.js as affecting global scope and that is a bug ?
There was a problem hiding this comment.
Afaik that just reads the two marker fields, which are all that get set to determine module-ness.
There was a problem hiding this comment.
can you add test and ensure that bar.js will be marked as affects global scope and foo.cjs as module so no affectsGlobalScope in buildInfo. I am pretty certain that it is broken right now.
|
Yeah - if you set moduleDetection to legacy you get our old extension-ignorant behavior. |
Component commits: 5d13ab2 moduleDetection: auto makes cjs files parse as modules, module: node sets moduleDetection: force Co-authored-by: Wesley Wigham <t-weswig@microsoft.com>
module: nodesetsmoduleDetection: force, per our discussion at yesterday's design meeting.Fixes #49207