- 
                Notifications
    
You must be signed in to change notification settings  - Fork 13.1k
 
          Support require(esm) in --module nodenext
          #60761
        
          New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| 
           Thanks for the PR! It looks like you've changed the TSServer protocol in some way. Please ensure that any changes here don't break consumers of the current TSServer API. For some extra review, we'll ping @sheetalkamat, @mjbvz, @zkat, and @joj for you. Feel free to loop in other consumers/maintainers if necessary.  | 
    
| 
           Looks like you're introducing a change to the public API surface area. If this includes breaking changes, please document them on our wiki's API Breaking Changes page. Also, please make sure @DanielRosenwasser and @RyanCavanaugh are aware of the changes, just as a heads up.  | 
    
| 
           I will probably release Node v20 (maybe the backport for require(esm)) around half of January 🙂  | 
    
590892b    to
    0dda037      
    Compare
  
    | 
           @marco-ippolito things still look good for backporting?  | 
    
          
 It might take a bit longer than expected due to the complexity of the backport, @joyeecheung is actively working on it. Ill keep here updated.  | 
    
| 
           We won't actually be able to fully backport   | 
    
| 
           Since the backport won’t happen until after 5.8 stable is out, I think the best thing to do might be to put this functionality only in   | 
    
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code LGTM but I know the naming very much depends on Node's scheduling and our own scheduling.
--module node20 with require(esm) supportrequire(esm) in --module nodenext
      There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving a second time, but I do enjoy how "make require(ESM) work" is just a one line change 😄
| 
           Hi, as commented by Marco before the backport was more challenging than we thought, though there's still hope to get it out in the March release. See nodejs/node#52697 (comment) and nodejs/node#56730 for more information about the progress.  | 
    
| 
           If the March release contains the backport, that will be on track for TypeScript 5.9. 5.8 stable is scheduled to come out in February.  | 
    
| 
           Wish: Show the tables (maybe only the one for the most recent version of TypeScript) in the documentation somewhere. I find them very useful.  | 
    
          import packageJson from '../package.json' with { type: 'json' };Code above will cause  TS 5.9 should defaultly allow it without   | 
    
| 
           @rauschma they’re here now: https://www.typescriptlang.org/docs/handbook/modules/reference.html#node16-node18-nodenext @zanminkian I agree.  | 
    
Fixes #60534
require(esm)is currently unflagged in Node.js v22,but may be in v20 by the time this PR lands for 5.8. We’ll have a discussion about the flag name if it doesn’t happen by 5.8-beta.EDIT: the backport will not come in time for 5.8; we are only changing--module nodenexthere, and will aim to make a--module node20in 5.9.This PR does not currently attempt to error on
requirecalls of async modules (those with top-levelawait). We do not emit any special marker in declaration files indicating the presence of TLA, which is a prerequisite. My suspicion is that the sentiment will be that a static check for async modules in therequiregraph is not worth the pain of making a backward-incompatible declaration file change.The other change in this PR is that import assertions are now prohibited in
--module nodenext, since Node.js v22+ does not parse them. Since there have been a lot of module target changes in fast succession, here’s the summary:5.6
targetmoduleResolutiones2022node16esnextnodenext5.7.3
targetmoduleResolutiones2022node16esnextnodenexttype "json"5.8
targetmoduleResolutiones2022node16es2022node16type "json"esnextnodenexttype "json"5.9 (planned)
targetmoduleResolutiones2022node16es2022node16type "json"es2023node16type "json"esnextnodenexttype "json"