Simplify extension priorities and move dts to lowest priority by weswigham · Pull Request #34713 · microsoft/TypeScript

Wesley Wigham (weswigham) · 2019-10-24T17:59:15Z

Where there are js (or json) files side-by-side with a declaration file of the same name, we now only load the .js file via wildcard. The declaration file can still be included via other means, but will no longer be implicitly included when allowJs is on. (Consequently, now if you have allowJs and declaration on and are using a wildcard matcher, repeated invocations of the compiler should now find the same set of inputs - at least via wildcard lookup.)

Technically speaking, I also removed all the extension priority groups to simplify extension priority handling - we do not appear to have any test cases this affects, but I do wonder if ranking .ts higher than .tsx is observable - in theory, it's not, since inputs are lexicographically ordered, so we'd always find the .ts before the .tsx before, anyway, so the extension priorities only had the affect of grouping declaration files with .js and .jsx files (which we now no longer wish to do).

… and move dts to lowest priority

Wesley Wigham (weswigham) · 2019-10-24T18:01:17Z

cc Ryan Cavanaugh (@RyanCavanaugh) who knows the origin story for the extension priority system and can maybe drop some knowledge as to if it still has good reason to be once .d.ts ranks lower than everything else.

Wesley Wigham (weswigham) · 2020-02-24T22:28:26Z

reping Ryan Cavanaugh (@RyanCavanaugh) again I guess

Nathan Shively-Sanders (sandersn) · 2020-03-04T23:38:33Z

Sheetal Nandi (@sheetalkamat) probably has opinions too.

Nathan Shively-Sanders (sandersn) · 2020-03-09T23:54:18Z

This is one of the hilarious PRs that doesn't load the reviewers list so I assigned both Sheetal Nandi (@sheetalkamat) and Ryan Cavanaugh (@RyanCavanaugh) instead of putting both in the reviewers list.

Sheetal Nandi (sheetalkamat) · 2020-03-10T17:48:11Z

 */
 export const supportedTSExtensions: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Dts];
- export const supportedTSExtensionsWithJson: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Dts, Extension.Json];
+ export const supportedTSExtensionsWithJson: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Json, Extension.Dts];


This isn't ideal I think...
Consider scenario::
// moduleA.tsimport{x}from"./moduleB";// moduleB.jsexportconstx=10;
When you build first time files in your program with allowJs and emitDeclarationsOnly will be:
moduleA.ts, moduleB.js
Next time they will be
moduleA.ts, moduleB.d.ts and moduleB.js since module resolution prefers up d.ts over .js

That's what we do today. This PR fixes that, such that the .d.ts is never preferred if the js is present, assuming allowJs is on.

What I mean is rootFiles will be moduleA.ts and moduleB.js but final list of files will contain .d.ts since that's what module resolution will resolve to? https://github.com/microsoft/TypeScript/blob/master/src/compiler/moduleNameResolver.ts#L1096

Hm, yeah, the order we check extensions in module resolution likely needs to match the order wildcards use. I'll look at changing it to use the same source, ideally.

Ryan Cavanaugh (RyanCavanaugh) · 2020-03-10T22:48:27Z

The root cause of .d.ts being lowest priority is that .d.ts can be a build output, and we always want to prefer build inputs to build outputs since otherwise we'd get "stuck" in a state where the developer would have to clean their outputs to get a correct fresh build. The interaction with .json in play now is obviously very subtle and we need to come up with a coherent story about what that means.

I'm pretty nervous about breaking someone's odd build setup (because let's be honest the test coverage in this area is less than great) when the associated issue here doesn't really have customer reports yet. Simplification is good but we can put this on the shelf for the time being and come back to it when we have a more concrete idea of what scenarios are being addressed.

Wesley Wigham (weswigham) · 2020-03-10T22:50:25Z

The interaction with .json in play now is obviously very subtle and we need to come up with a coherent story about what that means.

Not just json - jsx? with allowJs as well. (Which is actually more of a problem, imo)

…Script into extension-priority-revamp

Sheetal Nandi (sheetalkamat) · 2020-03-11T00:23:44Z

Module resolution, wild card matching are mingled.. when resolving module you want to have .d.ts at higher priority than .js because those have better info especially if those files are from some external source.. say node_modules is simplest case but people have weird module resolution setups where those might not be in node_modules So in my opinion this makes it more complicated and unless we have cleared up rules on when to prefer which extension this is going to be complicated.. I agree with Ryan Cavanaugh (@RyanCavanaugh) that this needs to be addressed when we have sufficient reports of the issue and have concrete plan and matrix of scenarios of expectations.

Nathan Shively-Sanders (sandersn) · 2020-04-01T22:34:44Z

This PR hasn't seen any activity for quite a while, so I'm going to close it to keep the number of open PRs manageable. Feel free to open a fresh PR or continue the discussion here.

Wesley Wigham (weswigham) · 2019-10-24T17:59:15Z

Fixes#33623

Where there are js (or json) files side-by-side with a declaration file of the same name, we now only load the .js file via wildcard. The declaration file can still be included via other means, but will no longer be implicitly included when allowJs is on. (Consequently, now if you have allowJs and declaration on and are using a wildcard matcher, repeated invocations of the compiler should now find the same set of inputs - at least via wildcard lookup.)

Technically speaking, I also removed all the extension priority groups to simplify extension priority handling - we do not appear to have any test cases this affects, but I do wonder if ranking .ts higher than .tsx is observable - in theory, it's not, since inputs are lexicographically ordered, so we'd always find the .ts before the .tsx before, anyway, so the extension priorities only had the affect of grouping declaration files with .js and .jsx files (which we now no longer wish to do).

… and move dts to lowest priority

Wesley Wigham (weswigham) · 2019-10-24T18:01:17Z

cc Ryan Cavanaugh (@RyanCavanaugh) who knows the origin story for the extension priority system and can maybe drop some knowledge as to if it still has good reason to be once .d.ts ranks lower than everything else.

Wesley Wigham (weswigham) · 2020-02-24T22:28:26Z

reping Ryan Cavanaugh (@RyanCavanaugh) again I guess

Nathan Shively-Sanders (sandersn) · 2020-03-04T23:38:33Z

Sheetal Nandi (@sheetalkamat) probably has opinions too.

Nathan Shively-Sanders (sandersn) · 2020-03-09T23:54:18Z

This is one of the hilarious PRs that doesn't load the reviewers list so I assigned both Sheetal Nandi (@sheetalkamat) and Ryan Cavanaugh (@RyanCavanaugh) instead of putting both in the reviewers list.

Sheetal Nandi (sheetalkamat) · 2020-03-10T17:48:11Z

 */
 export const supportedTSExtensions: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Dts];
- export const supportedTSExtensionsWithJson: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Dts, Extension.Json];
+ export const supportedTSExtensionsWithJson: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Json, Extension.Dts];


This isn't ideal I think...
Consider scenario::
// moduleA.tsimport{x}from"./moduleB";// moduleB.jsexportconstx=10;
When you build first time files in your program with allowJs and emitDeclarationsOnly will be:
moduleA.ts, moduleB.js
Next time they will be
moduleA.ts, moduleB.d.ts and moduleB.js since module resolution prefers up d.ts over .js

That's what we do today. This PR fixes that, such that the .d.ts is never preferred if the js is present, assuming allowJs is on.

What I mean is rootFiles will be moduleA.ts and moduleB.js but final list of files will contain .d.ts since that's what module resolution will resolve to? https://github.com/microsoft/TypeScript/blob/master/src/compiler/moduleNameResolver.ts#L1096

Hm, yeah, the order we check extensions in module resolution likely needs to match the order wildcards use. I'll look at changing it to use the same source, ideally.

Ryan Cavanaugh (RyanCavanaugh) · 2020-03-10T22:48:27Z

The root cause of .d.ts being lowest priority is that .d.ts can be a build output, and we always want to prefer build inputs to build outputs since otherwise we'd get "stuck" in a state where the developer would have to clean their outputs to get a correct fresh build. The interaction with .json in play now is obviously very subtle and we need to come up with a coherent story about what that means.

I'm pretty nervous about breaking someone's odd build setup (because let's be honest the test coverage in this area is less than great) when the associated issue here doesn't really have customer reports yet. Simplification is good but we can put this on the shelf for the time being and come back to it when we have a more concrete idea of what scenarios are being addressed.

Wesley Wigham (weswigham) · 2020-03-10T22:50:25Z

The interaction with .json in play now is obviously very subtle and we need to come up with a coherent story about what that means.

Not just json - jsx? with allowJs as well. (Which is actually more of a problem, imo)

…Script into extension-priority-revamp

Sheetal Nandi (sheetalkamat) · 2020-03-11T00:23:44Z

Module resolution, wild card matching are mingled.. when resolving module you want to have .d.ts at higher priority than .js because those have better info especially if those files are from some external source.. say node_modules is simplest case but people have weird module resolution setups where those might not be in node_modules So in my opinion this makes it more complicated and unless we have cleared up rules on when to prefer which extension this is going to be complicated.. I agree with Ryan Cavanaugh (@RyanCavanaugh) that this needs to be addressed when we have sufficient reports of the issue and have concrete plan and matrix of scenarios of expectations.

Nathan Shively-Sanders (sandersn) · 2020-04-01T22:34:44Z

This PR hasn't seen any activity for quite a while, so I'm going to close it to keep the number of open PRs manageable. Feel free to open a fresh PR or continue the discussion here.

Wesley Wigham (weswigham) · 2019-10-24T17:59:15Z

Fixes#33623

Where there are js (or json) files side-by-side with a declaration file of the same name, we now only load the .js file via wildcard. The declaration file can still be included via other means, but will no longer be implicitly included when allowJs is on. (Consequently, now if you have allowJs and declaration on and are using a wildcard matcher, repeated invocations of the compiler should now find the same set of inputs - at least via wildcard lookup.)

Technically speaking, I also removed all the extension priority groups to simplify extension priority handling - we do not appear to have any test cases this affects, but I do wonder if ranking .ts higher than .tsx is observable - in theory, it's not, since inputs are lexicographically ordered, so we'd always find the .ts before the .tsx before, anyway, so the extension priorities only had the affect of grouping declaration files with .js and .jsx files (which we now no longer wish to do).

… and move dts to lowest priority

Wesley Wigham (weswigham) · 2019-10-24T18:01:17Z

cc Ryan Cavanaugh (@RyanCavanaugh) who knows the origin story for the extension priority system and can maybe drop some knowledge as to if it still has good reason to be once .d.ts ranks lower than everything else.

Wesley Wigham (weswigham) · 2020-02-24T22:28:26Z

reping Ryan Cavanaugh (@RyanCavanaugh) again I guess

Nathan Shively-Sanders (sandersn) · 2020-03-04T23:38:33Z

Sheetal Nandi (@sheetalkamat) probably has opinions too.

Nathan Shively-Sanders (sandersn) · 2020-03-09T23:54:18Z

This is one of the hilarious PRs that doesn't load the reviewers list so I assigned both Sheetal Nandi (@sheetalkamat) and Ryan Cavanaugh (@RyanCavanaugh) instead of putting both in the reviewers list.

Sheetal Nandi (sheetalkamat) · 2020-03-10T17:48:11Z

 */
 export const supportedTSExtensions: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Dts];
- export const supportedTSExtensionsWithJson: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Dts, Extension.Json];
+ export const supportedTSExtensionsWithJson: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Json, Extension.Dts];


This isn't ideal I think...
Consider scenario::
// moduleA.tsimport{x}from"./moduleB";// moduleB.jsexportconstx=10;
When you build first time files in your program with allowJs and emitDeclarationsOnly will be:
moduleA.ts, moduleB.js
Next time they will be
moduleA.ts, moduleB.d.ts and moduleB.js since module resolution prefers up d.ts over .js

That's what we do today. This PR fixes that, such that the .d.ts is never preferred if the js is present, assuming allowJs is on.

What I mean is rootFiles will be moduleA.ts and moduleB.js but final list of files will contain .d.ts since that's what module resolution will resolve to? https://github.com/microsoft/TypeScript/blob/master/src/compiler/moduleNameResolver.ts#L1096

Hm, yeah, the order we check extensions in module resolution likely needs to match the order wildcards use. I'll look at changing it to use the same source, ideally.

Ryan Cavanaugh (RyanCavanaugh) · 2020-03-10T22:48:27Z

The root cause of .d.ts being lowest priority is that .d.ts can be a build output, and we always want to prefer build inputs to build outputs since otherwise we'd get "stuck" in a state where the developer would have to clean their outputs to get a correct fresh build. The interaction with .json in play now is obviously very subtle and we need to come up with a coherent story about what that means.

I'm pretty nervous about breaking someone's odd build setup (because let's be honest the test coverage in this area is less than great) when the associated issue here doesn't really have customer reports yet. Simplification is good but we can put this on the shelf for the time being and come back to it when we have a more concrete idea of what scenarios are being addressed.

Wesley Wigham (weswigham) · 2020-03-10T22:50:25Z

The interaction with .json in play now is obviously very subtle and we need to come up with a coherent story about what that means.

Not just json - jsx? with allowJs as well. (Which is actually more of a problem, imo)

…Script into extension-priority-revamp

Sheetal Nandi (sheetalkamat) · 2020-03-11T00:23:44Z

Module resolution, wild card matching are mingled.. when resolving module you want to have .d.ts at higher priority than .js because those have better info especially if those files are from some external source.. say node_modules is simplest case but people have weird module resolution setups where those might not be in node_modules So in my opinion this makes it more complicated and unless we have cleared up rules on when to prefer which extension this is going to be complicated.. I agree with Ryan Cavanaugh (@RyanCavanaugh) that this needs to be addressed when we have sufficient reports of the issue and have concrete plan and matrix of scenarios of expectations.

Nathan Shively-Sanders (sandersn) · 2020-04-01T22:34:44Z

This PR hasn't seen any activity for quite a while, so I'm going to close it to keep the number of open PRs manageable. Feel free to open a fresh PR or continue the discussion here.

Wesley Wigham (weswigham) · 2019-10-24T17:59:15Z

Fixes#33623

Where there are js (or json) files side-by-side with a declaration file of the same name, we now only load the .js file via wildcard. The declaration file can still be included via other means, but will no longer be implicitly included when allowJs is on. (Consequently, now if you have allowJs and declaration on and are using a wildcard matcher, repeated invocations of the compiler should now find the same set of inputs - at least via wildcard lookup.)

Technically speaking, I also removed all the extension priority groups to simplify extension priority handling - we do not appear to have any test cases this affects, but I do wonder if ranking .ts higher than .tsx is observable - in theory, it's not, since inputs are lexicographically ordered, so we'd always find the .ts before the .tsx before, anyway, so the extension priorities only had the affect of grouping declaration files with .js and .jsx files (which we now no longer wish to do).

… and move dts to lowest priority

Wesley Wigham (weswigham) · 2019-10-24T18:01:17Z

cc Ryan Cavanaugh (@RyanCavanaugh) who knows the origin story for the extension priority system and can maybe drop some knowledge as to if it still has good reason to be once .d.ts ranks lower than everything else.

Wesley Wigham (weswigham) · 2020-02-24T22:28:26Z

reping Ryan Cavanaugh (@RyanCavanaugh) again I guess

Nathan Shively-Sanders (sandersn) · 2020-03-04T23:38:33Z

Sheetal Nandi (@sheetalkamat) probably has opinions too.

Nathan Shively-Sanders (sandersn) · 2020-03-09T23:54:18Z

This is one of the hilarious PRs that doesn't load the reviewers list so I assigned both Sheetal Nandi (@sheetalkamat) and Ryan Cavanaugh (@RyanCavanaugh) instead of putting both in the reviewers list.

Sheetal Nandi (sheetalkamat) · 2020-03-10T17:48:11Z

 */
 export const supportedTSExtensions: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Dts];
- export const supportedTSExtensionsWithJson: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Dts, Extension.Json];
+ export const supportedTSExtensionsWithJson: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Json, Extension.Dts];


This isn't ideal I think...
Consider scenario::
// moduleA.tsimport{x}from"./moduleB";// moduleB.jsexportconstx=10;
When you build first time files in your program with allowJs and emitDeclarationsOnly will be:
moduleA.ts, moduleB.js
Next time they will be
moduleA.ts, moduleB.d.ts and moduleB.js since module resolution prefers up d.ts over .js

That's what we do today. This PR fixes that, such that the .d.ts is never preferred if the js is present, assuming allowJs is on.

What I mean is rootFiles will be moduleA.ts and moduleB.js but final list of files will contain .d.ts since that's what module resolution will resolve to? https://github.com/microsoft/TypeScript/blob/master/src/compiler/moduleNameResolver.ts#L1096

Hm, yeah, the order we check extensions in module resolution likely needs to match the order wildcards use. I'll look at changing it to use the same source, ideally.

Ryan Cavanaugh (RyanCavanaugh) · 2020-03-10T22:48:27Z

The root cause of .d.ts being lowest priority is that .d.ts can be a build output, and we always want to prefer build inputs to build outputs since otherwise we'd get "stuck" in a state where the developer would have to clean their outputs to get a correct fresh build. The interaction with .json in play now is obviously very subtle and we need to come up with a coherent story about what that means.

I'm pretty nervous about breaking someone's odd build setup (because let's be honest the test coverage in this area is less than great) when the associated issue here doesn't really have customer reports yet. Simplification is good but we can put this on the shelf for the time being and come back to it when we have a more concrete idea of what scenarios are being addressed.

Wesley Wigham (weswigham) · 2020-03-10T22:50:25Z

The interaction with .json in play now is obviously very subtle and we need to come up with a coherent story about what that means.

Not just json - jsx? with allowJs as well. (Which is actually more of a problem, imo)

…Script into extension-priority-revamp

Sheetal Nandi (sheetalkamat) · 2020-03-11T00:23:44Z

Module resolution, wild card matching are mingled.. when resolving module you want to have .d.ts at higher priority than .js because those have better info especially if those files are from some external source.. say node_modules is simplest case but people have weird module resolution setups where those might not be in node_modules So in my opinion this makes it more complicated and unless we have cleared up rules on when to prefer which extension this is going to be complicated.. I agree with Ryan Cavanaugh (@RyanCavanaugh) that this needs to be addressed when we have sufficient reports of the issue and have concrete plan and matrix of scenarios of expectations.

Nathan Shively-Sanders (sandersn) · 2020-04-01T22:34:44Z

This PR hasn't seen any activity for quite a while, so I'm going to close it to keep the number of open PRs manageable. Feel free to open a fresh PR or continue the discussion here.

Wesley Wigham (weswigham) · 2019-10-24T17:59:15Z

Fixes#33623

Where there are js (or json) files side-by-side with a declaration file of the same name, we now only load the .js file via wildcard. The declaration file can still be included via other means, but will no longer be implicitly included when allowJs is on. (Consequently, now if you have allowJs and declaration on and are using a wildcard matcher, repeated invocations of the compiler should now find the same set of inputs - at least via wildcard lookup.)

Technically speaking, I also removed all the extension priority groups to simplify extension priority handling - we do not appear to have any test cases this affects, but I do wonder if ranking .ts higher than .tsx is observable - in theory, it's not, since inputs are lexicographically ordered, so we'd always find the .ts before the .tsx before, anyway, so the extension priorities only had the affect of grouping declaration files with .js and .jsx files (which we now no longer wish to do).

… and move dts to lowest priority

Wesley Wigham (weswigham) · 2019-10-24T18:01:17Z

cc Ryan Cavanaugh (@RyanCavanaugh) who knows the origin story for the extension priority system and can maybe drop some knowledge as to if it still has good reason to be once .d.ts ranks lower than everything else.

Wesley Wigham (weswigham) · 2020-02-24T22:28:26Z

reping Ryan Cavanaugh (@RyanCavanaugh) again I guess

Nathan Shively-Sanders (sandersn) · 2020-03-04T23:38:33Z

Sheetal Nandi (@sheetalkamat) probably has opinions too.

Nathan Shively-Sanders (sandersn) · 2020-03-09T23:54:18Z

This is one of the hilarious PRs that doesn't load the reviewers list so I assigned both Sheetal Nandi (@sheetalkamat) and Ryan Cavanaugh (@RyanCavanaugh) instead of putting both in the reviewers list.

Sheetal Nandi (sheetalkamat) · 2020-03-10T17:48:11Z

 */
 export const supportedTSExtensions: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Dts];
- export const supportedTSExtensionsWithJson: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Dts, Extension.Json];
+ export const supportedTSExtensionsWithJson: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Json, Extension.Dts];


This isn't ideal I think...
Consider scenario::
// moduleA.tsimport{x}from"./moduleB";// moduleB.jsexportconstx=10;
When you build first time files in your program with allowJs and emitDeclarationsOnly will be:
moduleA.ts, moduleB.js
Next time they will be
moduleA.ts, moduleB.d.ts and moduleB.js since module resolution prefers up d.ts over .js

That's what we do today. This PR fixes that, such that the .d.ts is never preferred if the js is present, assuming allowJs is on.

What I mean is rootFiles will be moduleA.ts and moduleB.js but final list of files will contain .d.ts since that's what module resolution will resolve to? https://github.com/microsoft/TypeScript/blob/master/src/compiler/moduleNameResolver.ts#L1096

Hm, yeah, the order we check extensions in module resolution likely needs to match the order wildcards use. I'll look at changing it to use the same source, ideally.

Ryan Cavanaugh (RyanCavanaugh) · 2020-03-10T22:48:27Z

The root cause of .d.ts being lowest priority is that .d.ts can be a build output, and we always want to prefer build inputs to build outputs since otherwise we'd get "stuck" in a state where the developer would have to clean their outputs to get a correct fresh build. The interaction with .json in play now is obviously very subtle and we need to come up with a coherent story about what that means.

I'm pretty nervous about breaking someone's odd build setup (because let's be honest the test coverage in this area is less than great) when the associated issue here doesn't really have customer reports yet. Simplification is good but we can put this on the shelf for the time being and come back to it when we have a more concrete idea of what scenarios are being addressed.

Wesley Wigham (weswigham) · 2020-03-10T22:50:25Z

The interaction with .json in play now is obviously very subtle and we need to come up with a coherent story about what that means.

Not just json - jsx? with allowJs as well. (Which is actually more of a problem, imo)

…Script into extension-priority-revamp

Sheetal Nandi (sheetalkamat) · 2020-03-11T00:23:44Z

Module resolution, wild card matching are mingled.. when resolving module you want to have .d.ts at higher priority than .js because those have better info especially if those files are from some external source.. say node_modules is simplest case but people have weird module resolution setups where those might not be in node_modules So in my opinion this makes it more complicated and unless we have cleared up rules on when to prefer which extension this is going to be complicated.. I agree with Ryan Cavanaugh (@RyanCavanaugh) that this needs to be addressed when we have sufficient reports of the issue and have concrete plan and matrix of scenarios of expectations.

Nathan Shively-Sanders (sandersn) · 2020-04-01T22:34:44Z

This PR hasn't seen any activity for quite a while, so I'm going to close it to keep the number of open PRs manageable. Feel free to open a fresh PR or continue the discussion here.

Wesley Wigham (weswigham) · 2019-10-24T17:59:15Z

Fixes#33623

Where there are js (or json) files side-by-side with a declaration file of the same name, we now only load the .js file via wildcard. The declaration file can still be included via other means, but will no longer be implicitly included when allowJs is on. (Consequently, now if you have allowJs and declaration on and are using a wildcard matcher, repeated invocations of the compiler should now find the same set of inputs - at least via wildcard lookup.)

Technically speaking, I also removed all the extension priority groups to simplify extension priority handling - we do not appear to have any test cases this affects, but I do wonder if ranking .ts higher than .tsx is observable - in theory, it's not, since inputs are lexicographically ordered, so we'd always find the .ts before the .tsx before, anyway, so the extension priorities only had the affect of grouping declaration files with .js and .jsx files (which we now no longer wish to do).

… and move dts to lowest priority

Wesley Wigham (weswigham) · 2019-10-24T18:01:17Z

cc Ryan Cavanaugh (@RyanCavanaugh) who knows the origin story for the extension priority system and can maybe drop some knowledge as to if it still has good reason to be once .d.ts ranks lower than everything else.

Wesley Wigham (weswigham) · 2020-02-24T22:28:26Z

reping Ryan Cavanaugh (@RyanCavanaugh) again I guess

Nathan Shively-Sanders (sandersn) · 2020-03-04T23:38:33Z

Sheetal Nandi (@sheetalkamat) probably has opinions too.

Nathan Shively-Sanders (sandersn) · 2020-03-09T23:54:18Z

This is one of the hilarious PRs that doesn't load the reviewers list so I assigned both Sheetal Nandi (@sheetalkamat) and Ryan Cavanaugh (@RyanCavanaugh) instead of putting both in the reviewers list.

Sheetal Nandi (sheetalkamat) · 2020-03-10T17:48:11Z

 */
 export const supportedTSExtensions: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Dts];
- export const supportedTSExtensionsWithJson: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Dts, Extension.Json];
+ export const supportedTSExtensionsWithJson: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Json, Extension.Dts];


This isn't ideal I think...
Consider scenario::
// moduleA.tsimport{x}from"./moduleB";// moduleB.jsexportconstx=10;
When you build first time files in your program with allowJs and emitDeclarationsOnly will be:
moduleA.ts, moduleB.js
Next time they will be
moduleA.ts, moduleB.d.ts and moduleB.js since module resolution prefers up d.ts over .js

That's what we do today. This PR fixes that, such that the .d.ts is never preferred if the js is present, assuming allowJs is on.

What I mean is rootFiles will be moduleA.ts and moduleB.js but final list of files will contain .d.ts since that's what module resolution will resolve to? https://github.com/microsoft/TypeScript/blob/master/src/compiler/moduleNameResolver.ts#L1096

Hm, yeah, the order we check extensions in module resolution likely needs to match the order wildcards use. I'll look at changing it to use the same source, ideally.

Ryan Cavanaugh (RyanCavanaugh) · 2020-03-10T22:48:27Z

The root cause of .d.ts being lowest priority is that .d.ts can be a build output, and we always want to prefer build inputs to build outputs since otherwise we'd get "stuck" in a state where the developer would have to clean their outputs to get a correct fresh build. The interaction with .json in play now is obviously very subtle and we need to come up with a coherent story about what that means.

I'm pretty nervous about breaking someone's odd build setup (because let's be honest the test coverage in this area is less than great) when the associated issue here doesn't really have customer reports yet. Simplification is good but we can put this on the shelf for the time being and come back to it when we have a more concrete idea of what scenarios are being addressed.

Wesley Wigham (weswigham) · 2020-03-10T22:50:25Z

The interaction with .json in play now is obviously very subtle and we need to come up with a coherent story about what that means.

Not just json - jsx? with allowJs as well. (Which is actually more of a problem, imo)

…Script into extension-priority-revamp

Sheetal Nandi (sheetalkamat) · 2020-03-11T00:23:44Z

Module resolution, wild card matching are mingled.. when resolving module you want to have .d.ts at higher priority than .js because those have better info especially if those files are from some external source.. say node_modules is simplest case but people have weird module resolution setups where those might not be in node_modules So in my opinion this makes it more complicated and unless we have cleared up rules on when to prefer which extension this is going to be complicated.. I agree with Ryan Cavanaugh (@RyanCavanaugh) that this needs to be addressed when we have sufficient reports of the issue and have concrete plan and matrix of scenarios of expectations.

Nathan Shively-Sanders (sandersn) · 2020-04-01T22:34:44Z

This PR hasn't seen any activity for quite a while, so I'm going to close it to keep the number of open PRs manageable. Feel free to open a fresh PR or continue the discussion here.

Wesley Wigham (weswigham) · 2019-10-24T17:59:15Z

Fixes#33623

Where there are js (or json) files side-by-side with a declaration file of the same name, we now only load the .js file via wildcard. The declaration file can still be included via other means, but will no longer be implicitly included when allowJs is on. (Consequently, now if you have allowJs and declaration on and are using a wildcard matcher, repeated invocations of the compiler should now find the same set of inputs - at least via wildcard lookup.)

Technically speaking, I also removed all the extension priority groups to simplify extension priority handling - we do not appear to have any test cases this affects, but I do wonder if ranking .ts higher than .tsx is observable - in theory, it's not, since inputs are lexicographically ordered, so we'd always find the .ts before the .tsx before, anyway, so the extension priorities only had the affect of grouping declaration files with .js and .jsx files (which we now no longer wish to do).

… and move dts to lowest priority

Wesley Wigham (weswigham) · 2019-10-24T18:01:17Z

cc Ryan Cavanaugh (@RyanCavanaugh) who knows the origin story for the extension priority system and can maybe drop some knowledge as to if it still has good reason to be once .d.ts ranks lower than everything else.

Wesley Wigham (weswigham) · 2020-02-24T22:28:26Z

reping Ryan Cavanaugh (@RyanCavanaugh) again I guess

Nathan Shively-Sanders (sandersn) · 2020-03-04T23:38:33Z

Sheetal Nandi (@sheetalkamat) probably has opinions too.

Nathan Shively-Sanders (sandersn) · 2020-03-09T23:54:18Z

This is one of the hilarious PRs that doesn't load the reviewers list so I assigned both Sheetal Nandi (@sheetalkamat) and Ryan Cavanaugh (@RyanCavanaugh) instead of putting both in the reviewers list.

Sheetal Nandi (sheetalkamat) · 2020-03-10T17:48:11Z

 */
 export const supportedTSExtensions: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Dts];
- export const supportedTSExtensionsWithJson: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Dts, Extension.Json];
+ export const supportedTSExtensionsWithJson: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Json, Extension.Dts];


This isn't ideal I think...
Consider scenario::
// moduleA.tsimport{x}from"./moduleB";// moduleB.jsexportconstx=10;
When you build first time files in your program with allowJs and emitDeclarationsOnly will be:
moduleA.ts, moduleB.js
Next time they will be
moduleA.ts, moduleB.d.ts and moduleB.js since module resolution prefers up d.ts over .js

That's what we do today. This PR fixes that, such that the .d.ts is never preferred if the js is present, assuming allowJs is on.

What I mean is rootFiles will be moduleA.ts and moduleB.js but final list of files will contain .d.ts since that's what module resolution will resolve to? https://github.com/microsoft/TypeScript/blob/master/src/compiler/moduleNameResolver.ts#L1096

Hm, yeah, the order we check extensions in module resolution likely needs to match the order wildcards use. I'll look at changing it to use the same source, ideally.

Ryan Cavanaugh (RyanCavanaugh) · 2020-03-10T22:48:27Z

The root cause of .d.ts being lowest priority is that .d.ts can be a build output, and we always want to prefer build inputs to build outputs since otherwise we'd get "stuck" in a state where the developer would have to clean their outputs to get a correct fresh build. The interaction with .json in play now is obviously very subtle and we need to come up with a coherent story about what that means.

I'm pretty nervous about breaking someone's odd build setup (because let's be honest the test coverage in this area is less than great) when the associated issue here doesn't really have customer reports yet. Simplification is good but we can put this on the shelf for the time being and come back to it when we have a more concrete idea of what scenarios are being addressed.

Wesley Wigham (weswigham) · 2020-03-10T22:50:25Z

The interaction with .json in play now is obviously very subtle and we need to come up with a coherent story about what that means.

Not just json - jsx? with allowJs as well. (Which is actually more of a problem, imo)

…Script into extension-priority-revamp

Sheetal Nandi (sheetalkamat) · 2020-03-11T00:23:44Z

Module resolution, wild card matching are mingled.. when resolving module you want to have .d.ts at higher priority than .js because those have better info especially if those files are from some external source.. say node_modules is simplest case but people have weird module resolution setups where those might not be in node_modules So in my opinion this makes it more complicated and unless we have cleared up rules on when to prefer which extension this is going to be complicated.. I agree with Ryan Cavanaugh (@RyanCavanaugh) that this needs to be addressed when we have sufficient reports of the issue and have concrete plan and matrix of scenarios of expectations.

Nathan Shively-Sanders (sandersn) · 2020-04-01T22:34:44Z

This PR hasn't seen any activity for quite a while, so I'm going to close it to keep the number of open PRs manageable. Feel free to open a fresh PR or continue the discussion here.

Wesley Wigham (weswigham) · 2019-10-24T17:59:15Z

Fixes#33623

Where there are js (or json) files side-by-side with a declaration file of the same name, we now only load the .js file via wildcard. The declaration file can still be included via other means, but will no longer be implicitly included when allowJs is on. (Consequently, now if you have allowJs and declaration on and are using a wildcard matcher, repeated invocations of the compiler should now find the same set of inputs - at least via wildcard lookup.)

Technically speaking, I also removed all the extension priority groups to simplify extension priority handling - we do not appear to have any test cases this affects, but I do wonder if ranking .ts higher than .tsx is observable - in theory, it's not, since inputs are lexicographically ordered, so we'd always find the .ts before the .tsx before, anyway, so the extension priorities only had the affect of grouping declaration files with .js and .jsx files (which we now no longer wish to do).

… and move dts to lowest priority

Wesley Wigham (weswigham) · 2019-10-24T18:01:17Z

cc Ryan Cavanaugh (@RyanCavanaugh) who knows the origin story for the extension priority system and can maybe drop some knowledge as to if it still has good reason to be once .d.ts ranks lower than everything else.

Wesley Wigham (weswigham) · 2020-02-24T22:28:26Z

reping Ryan Cavanaugh (@RyanCavanaugh) again I guess

Nathan Shively-Sanders (sandersn) · 2020-03-04T23:38:33Z

Sheetal Nandi (@sheetalkamat) probably has opinions too.

Nathan Shively-Sanders (sandersn) · 2020-03-09T23:54:18Z

This is one of the hilarious PRs that doesn't load the reviewers list so I assigned both Sheetal Nandi (@sheetalkamat) and Ryan Cavanaugh (@RyanCavanaugh) instead of putting both in the reviewers list.

Sheetal Nandi (sheetalkamat) · 2020-03-10T17:48:11Z

 */
 export const supportedTSExtensions: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Dts];
- export const supportedTSExtensionsWithJson: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Dts, Extension.Json];
+ export const supportedTSExtensionsWithJson: readonly Extension[] = [Extension.Ts, Extension.Tsx, Extension.Json, Extension.Dts];


This isn't ideal I think...
Consider scenario::
// moduleA.tsimport{x}from"./moduleB";// moduleB.jsexportconstx=10;
When you build first time files in your program with allowJs and emitDeclarationsOnly will be:
moduleA.ts, moduleB.js
Next time they will be
moduleA.ts, moduleB.d.ts and moduleB.js since module resolution prefers up d.ts over .js

That's what we do today. This PR fixes that, such that the .d.ts is never preferred if the js is present, assuming allowJs is on.

What I mean is rootFiles will be moduleA.ts and moduleB.js but final list of files will contain .d.ts since that's what module resolution will resolve to? https://github.com/microsoft/TypeScript/blob/master/src/compiler/moduleNameResolver.ts#L1096

Hm, yeah, the order we check extensions in module resolution likely needs to match the order wildcards use. I'll look at changing it to use the same source, ideally.

Ryan Cavanaugh (RyanCavanaugh) · 2020-03-10T22:48:27Z

The root cause of .d.ts being lowest priority is that .d.ts can be a build output, and we always want to prefer build inputs to build outputs since otherwise we'd get "stuck" in a state where the developer would have to clean their outputs to get a correct fresh build. The interaction with .json in play now is obviously very subtle and we need to come up with a coherent story about what that means.

I'm pretty nervous about breaking someone's odd build setup (because let's be honest the test coverage in this area is less than great) when the associated issue here doesn't really have customer reports yet. Simplification is good but we can put this on the shelf for the time being and come back to it when we have a more concrete idea of what scenarios are being addressed.

Wesley Wigham (weswigham) · 2020-03-10T22:50:25Z

The interaction with .json in play now is obviously very subtle and we need to come up with a coherent story about what that means.

Not just json - jsx? with allowJs as well. (Which is actually more of a problem, imo)

…Script into extension-priority-revamp

Sheetal Nandi (sheetalkamat) · 2020-03-11T00:23:44Z

Module resolution, wild card matching are mingled.. when resolving module you want to have .d.ts at higher priority than .js because those have better info especially if those files are from some external source.. say node_modules is simplest case but people have weird module resolution setups where those might not be in node_modules So in my opinion this makes it more complicated and unless we have cleared up rules on when to prefer which extension this is going to be complicated.. I agree with Ryan Cavanaugh (@RyanCavanaugh) that this needs to be addressed when we have sufficient reports of the issue and have concrete plan and matrix of scenarios of expectations.

Nathan Shively-Sanders (sandersn) · 2020-04-01T22:34:44Z

This PR hasn't seen any activity for quite a while, so I'm going to close it to keep the number of open PRs manageable. Feel free to open a fresh PR or continue the discussion here.

Simplify extension priorities, handle custom extensions better (ish),…
55343fb
… and move dts to lowest priority

Daniel Rosenwasser (DanielRosenwasser) mentioned this pull request Dec 9, 2019
Design Meeting Notes, 11/22/2019 #35589
Closed

Nathan Shively-Sanders (sandersn) added the For Milestone Bug PRs that fix a bug with a specific milestone label Feb 1, 2020

TypeScript Bot (typescript-bot) assigned Wesley Wigham (weswigham)Feb 1, 2020

TypeScript Bot (typescript-bot) added the Author: Team label Feb 1, 2020

Merge branch 'master' into extension-priority-revamp
55d5c47

Nathan Shively-Sanders (sandersn) assigned Ryan Cavanaugh (RyanCavanaugh) and Sheetal Nandi (sheetalkamat)Mar 9, 2020

Nathan Shively-Sanders (sandersn) unassigned Wesley Wigham (weswigham)Mar 9, 2020

Sheetal Nandi (sheetalkamat) reviewed Mar 10, 2020
View reviewed changes

Merge branch 'master' into extension-priority-revamp
12debca

Merge branch 'extension-priority-revamp' of github.com:weswigham/Type…
415500c
…Script into extension-priority-revamp

Nathan Shively-Sanders (sandersn) unassigned Ryan Cavanaugh (RyanCavanaugh)Mar 27, 2020

Nathan Shively-Sanders (sandersn) closed this Apr 1, 2020

Microsoft (microsoft) locked as resolved and limited conversation to collaborators Oct 21, 2025