Uh oh!
There was an error while loading. Please reload this page.
Support resolving @typescript/[lib] in node modules - #45771
Conversation
orta
commented
Sep 14, 2021
@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 |
typescript-bot
commented
Sep 14, 2021
@orta Here they are:Comparison Report - main..45771
System
Hosts
Scenarios
Developer Information: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
orta
commented
Sep 14, 2021
Actually trying this IRL is giving me unexpected results, What I want: Perhaps instead of |
orta
commented
Sep 14, 2021
Confirming to myself: Revised code: Does: The fact that whether the file exists is irrelevant (and so I think |
orta
commented
Sep 14, 2021
Looking through the code, this isn't necessarily on a hot route but this does affect |
orta
commented
Sep 14, 2021
@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 |
andrewbranch
left a comment
There was a problem hiding this comment.
One nit then excited to try this out
Uh oh!
There was an error while loading. Please reload this page.
| 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 |
mikob
commented
Oct 20, 2021
has this been tested with yarn 3+? I get this error: |
mikob
commented
Oct 20, 2021
seems like a yarn issue, workaround here: yarnpkg/berry#1621 |
Did you use yarnpkg/berry#1621 (comment) e.g.: With |
mikob
commented
Oct 21, 2021
I went the other route and just specified @* at the end of the dependency line. |
alshdavid
commented
Nov 3, 2021
Can this be imported explicitly without globals being set? import{window,Window,console}from'@typescript/lib-dom' |
dlemfh
commented
Nov 3, 2021
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 |
orta
commented
Nov 3, 2021
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.tsdeclarevarfoobar: 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 |
andrewbranch
commented
Jan 25, 2023
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 |
cdaringe
commented
Feb 2, 2023
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 |
cdaringe
commented
Feb 2, 2023
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.