| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
This looks good, though it does make me consider, why do any transform on the lib file name at all? Package names can have dots, so there’s no reason our lookup name can’t be @typescript/lib.dom.d.ts, and then we wouldn’t have to do any of the name parsing. |
Sorry, something went wrong.
|
Maybe leaving on the .d.ts would look confusing to some people (though it’s not actually ambiguous), but I’d be tempted to at least leave the dots instead of dashes. I don’t guess it really matters, though. |
Sorry, something went wrong.
|
I think it's more about the form factor for how I think people would use it - for dom that means we can ship dom and dom.iterable correctly in a single package, instead of via 2 separate npm packages The same would then apply for 'my runtime's version of es2018' which you can opt-in specific files. |
Sorry, something went wrong.
|
Ah, I forgot about that 👍 |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Fixes #45993
#45771 introduced a way to write something like:
{ "dependencies": { "@typescript/dom": "npm:@types/web" } }This PR changes that to be:
{ "dependencies": { "@typescript/lib-dom": "npm:@types/web" } }Thus the node-style resolution for:
If you made a package which just sets up @typescript/lib-es2015/symbol-wellknown.d.ts without @typescript/lib-es2015/index.d.ts, then es2015 would still resolve to the TypeScript hosted version.