You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Triple-slash reference type directives can override the import mode used for their resolution (#47732)
* Triple-slash reference type directives can override the import mode used for their resolution
They now use the file's default mode by default, rather than always using commonjs. The new arguments to the
reference directive look like:
```ts
///<reference types="pkg" resolution-mode="require" />
```
or
```ts
///<reference types="pkg" resolution-mode="import" />
```
* Omit redundant import modes in emitter
* Add test for #47806
* Add server test for triple-slash reference mode overrides
* Move FileReference mode into helper
* Update tests/cases/conformance/node/nodeModulesTripleSlashReferenceModeOverride3.ts
Co-authored-by: Nathan Shively-Sanders <[email protected]>
Co-authored-by: Nathan Shively-Sanders <[email protected]>
// Unlike `import` statements, whose mode-calculating APIs are all guaranteed to return `undefined` if we're in an un-mode-ed module resolution
345
+
// setting, type references will return their target mode regardless of options because of how the parser works, so we guard against the mode being
346
+
// set in a non-modal module resolution setting here. Do note that our behavior is not particularly well defined when these mode-overriding imports
347
+
// are present in a non-modal project; while in theory we'd like to either ignore the mode or provide faithful modern resolution, depending on what we feel is best,
348
+
// in practice, not every cache has the options available to intelligently make the choice to ignore the mode request, and it's unclear how modern "faithful modern
349
+
// resolution" should be (`node12`? `nodenext`?). As such, witnessing a mode-overriding triple-slash reference in a non-modal module resolution
350
+
// context should _probably_ be an error - and that should likely be handled by the `Program` (which is what we do).
0 commit comments