Repository navigation
Move away from Classic module resolution as default for all module kinds #11434
Description
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
baseUrlandpathsproperties intsconfig.json.
After discussing with Vladimir Matveev (@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
Activity
kitsonk commentedon Oct 7, 2016
We (Dojo (@dojo)) were using
classicup until the release of 2.0 because thenoderesolution 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@typesand 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 commentedon Oct 9, 2016
Thanks for weighing in Kitson Kelly (@kitsonk). We knew that Dojo was using
classicin 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 toclassic.Aluan Haddad (@aluanhaddad), it'd also be good to get your thoughts here too.
aluanhaddad commentedon Oct 10, 2016
Daniel Rosenwasser (@DanielRosenwasser) I think this would be a positive change.
Having a non-relative import that resolves to a location not directly under the
baseUrlis likely to fail at runtime unless you have explicitly configured your loader to resolve it.classicresolution 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
noderesolution, for example its eagerness to resolve modules to anode_modulesdirectory above the location of a project, butclassicis not the answer.In the future, I hope to see more configurable resolution strategies but these would likely be deltas on the
nodestrategy.brhumphe commentedon Oct 19, 2016
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 commentedon May 15, 2019
Keywords: moduleResolution module resolution commonjs amd esmodule es5 es6 es2015
DanielRosenwasser commentedon May 15, 2019
Ryan Cavanaugh (@RyanCavanaugh)
DanielRosenwasser commentedon Jul 10, 2020
If someone wants to send a PR, I think that the hardest part would be updating the tests.
DanielRosenwasser commentedon May 23, 2022
This is probably no longer the solution we would want give the fact that there are 2 new module modes for ESM in Node.js, and Deno has its own rules.