Typescript: Move away from Classic module resolution as default for all module kinds

[DanielRosenwasser]

TypeScript's original module resolution strategy (the _Classic_ resolution strategy) has some strange behavior that apparently doesn't actually reflect any other resolution strategy. It seems strange that those using non-CommonJS emit targets get this behavior by default.

_Classic_ resolution also causes many disk probes during the walk up the project root - assuming that this strategy does eventually succeed in most cases, it seems like most uses could be subsumed by:

• Using relative paths.
• Modifying the baseUrl and paths properties in tsconfig.json.

After discussing with @vladima, we think it is worth considering switching the default resolution strategy for all module targets to _Node_.

Here's what needs to be done:

• [ ] Investigate existing tsconfig.jsons that target esXXXX` and have no explicit/implied resolution strategy.
• [ ] Determine the downstream effects to a change to defaults
• [ ] Determine if this change outweighs the potential breakage
• [ ] Implement if appropriate

[kitsonk]

We (@dojo) were using classic up until the release of 2.0 because the node resolution was causing us issues and we weren't using UMD definitions. Even though npm isn't the best package manager for web based applications, I think with the _magic_ of @types and UMD definitions the node resolution at design time compliments our AMD configuration at runtime.

The only problem we have now with focusing our code at AMD (although outputting UMD) is dealing with namespaced packages. We still have to "alias" those using ambient declarations.

[DanielRosenwasser]

Thanks for weighing in @kitsonk. We knew that Dojo was using classic in some capacity, but we figured that there shouldn't be any major changes, and for new projects people shouldn't be caught off guard by this behavior.

Additionally, we wouldn't remove classic, we'd only switch the defaults for non-CommonJS resolutions, so users could still opt back in to classic.

@aluanhaddad, it'd also be good to get your thoughts here too.

[aluanhaddad]

@DanielRosenwasser I think this would be a positive change.

Having a non-relative import that resolves to a location not directly under the baseUrl is likely to fail at runtime unless you have explicitly configured your loader to resolve it.

classic resolution is actually a refactoring hazard because you could move a module to an arbitrary child directory and not receive errors for non-relative imports that do in fact need to be updated.

I certainly have issues with aspects of node resolution, for example its eagerness to resolve modules to a node_modules directory _above_ the location of a project, but classic is not the answer.

In the future, I hope to see more configurable resolution strategies but these would likely be deltas on the node strategy.

[brhumphe]

I'm pretty new to typescript, and this unexpected behavior really tripped me up (see #11712 ). The vast majority of tutorials assume the user is developing with npm, including those on the official website, so the defaults should (from my noob-ish perspective) reflect that most common use case.

There are more than enough unexpected pitfalls in web development. Eliminating this one would be awesome.

[DanielRosenwasser]

Keywords: moduleResolution module resolution commonjs amd esmodule es5 es6 es2015

[DanielRosenwasser]

@RyanCavanaugh

[DanielRosenwasser]

If someone wants to send a PR, I think that the hardest part would be updating the tests.