Support resolving @typescript/[lib] in node modules
#45771
Conversation
typescript-bot
added
Author: Team
For Uncommitted Bug
|
@typescript-bot perf test |
|
Heya @orta, I've started to run the perf test suite on this PR at daa99ce. You can monitor the build here. Update: The results are in! |
|
Hey @orta, I've packed this into an installable tgz. You can install it for testing by referencing it in your and then running There is also a playground for this build and an npm module you can use via |
|
@orta Here they are:Comparison Report - main..45771
System
Hosts
Scenarios
Developer Information: |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Actually trying this IRL is giving me unexpected results, What I want: Perhaps instead of |
|
Confirming to myself: Revised code: Does: The fact that whether the file exists is irrelevant (and so I think |
|
Looking through the code, this isn't necessarily on a hot route but this does affect |
|
@typescript-bot pack this |
|
Hey @orta, I've packed this into an installable tgz. You can install it for testing by referencing it in your and then running There is also a playground for this build and an npm module you can use via |
src/compiler/program.ts
Outdated
| if (localOverride?.resolvedModule) { | ||
| return localOverride.resolvedModule.resolvedFileName; | ||
|
|
||
| const resolveFrom = combinePaths(currentDirectory, `/__lib_node_modules_lookup_${libFileName}__.ts`); |
There was a problem hiding this comment.
This always ignores currentDirectory because the latter argument is absolute.
There was a problem hiding this comment.
Guessing this didn’t break tests only because all the tests are rooted at /
|
I explored setting the node_modules to not be root, but the |
has this been tested with yarn 3+? I get this error: |
|
seems like a yarn issue, workaround here: yarnpkg/berry#1621 |
|
Did you use yarnpkg/berry#1621 (comment) e.g.: With |
|
I went the other route and just specified @* at the end of the dependency line. |
|
Can this be imported explicitly without globals being set? import { window, Window, console } from '@typescript/lib-dom' |
|
Great work! 👍 May I ask is it possible to use this feature to enforce my project to use specific node types e.g. What would I need to do if I wanted to not use node types altogether, even when my dependency is using node types? Concrete use case would be: a dependency library (which uses node types) forcibly introduces type overrides for |
No, that's being researched over at #43972
I don't think this can be too useful there - I think you might need some sort of pre-install script which checks. In theory #40468 could allow for it, but the underlaying issue is that everything in TS lives in a global type space and this at least lets you edit the 'ships with typescript' globals |
|
it's not clear to me exactly how to use this, having read the associated blog post.
"dependencies": {
// ...snip...
"@typescript/lib-dom": "workspace:concordance-env@*"
},$ tree node_modules/\@typescript/lib-dom/src/
node_modules/@typescript/lib-dom/src/
└── index.d.ts
# all my good stuff!// index.d.ts
declare var foobar: number;and specifying: {
"extends": "concordance-tsconfig/tsconfig.base.json",
"compilerOptions": {
// DOM is squashed with concordance env :)
"lib": ["DOM"]
}
}but the compiler isn't picking up my symbols 🤔, such as did I miss a crucial step? update--i had an |
|
Glad you figured it out, but it sounds like this feature isn’t what you want anyway. You’ve always been able to add arbitrary global type declaration files via the |
|
hey @andrewbranch, thanks!
kind of! set me straight. these are the kind of global types inclusion by types config field and/or triple-slashes:
what's missing is:
due to reasons, i cannot publish to DefTyped. feasibly i could for that reason, i thought "well, i could feasibly intercept one of the lib resolvers!". it ended up having other quirks, so i may pick a new path. but i'd love to have a |
|
Off the top of my head, I’m pretty sure both the |
|
Holy guacamole, why didnt i even try!? The docs are adequate, but I misinterpreted them. Thx |
Note that #46046 updated this implementation with adding
@typescript/lib-[x].Closes #45518 as an alternative which leaves the responsibilities of configuring the environment to your package manager. Re #45688 #45685 and #44795
This answer to supporting your own versions of in-built libraries uses the node_modules resolution structure to let you define libraries. The path lookup looks like:
lib.dom.d.ts->@typescript/domlib.dom.iterable.d.ts->@typescript/dom/iterablelib.es2015.symbol.wellknown.d.ts->@typescript/es2015/symbol-wellknownIf you made a package which just sets up
@typescript/es2015/symbol-wellknown.d.tswithout@typescript/es2015/index.d.ts, thenes2015would still resolve to the TypeScript hosted version.All JS dependency managers support this syntax:
This gives people the chance to make their own package with the
.d.tsfiles in the right place and then set it up safely in their own project similar to@types. As we own@typescript/xon npm (and only have a few modules like@typescript/vfs, none of which clash) - then we don't need to worry about 'what happens if someone accidentally includes it twice' via the dependency tree.