-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Rules for scoped packages with local definitions differs from @types definitions. #30599
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
There is special logic when resolving modules that You might be able to make something with path mapping happen, but I haven't tried. |
Would it be a reasonable feature request to have all As a user, my expectation is that I often learn how to create type definitions by looking at DefinitelyTyped, and when something that works there doesn't work in my local project I'm left in a situation where I need to find another source of example to work from. |
In the meantime, is there any workaround that would allow me to define a scoped package locally other than via the |
We can always have more options, but Path mapping is generally the right way to specify a different file location for a non-relative module name. |
Something that is tickling my brain about your explanation is that if the module is not scope (and thus I can name the folder exactly), the definition works when I copy it into any I think ultimately that is why this feels like a bug, because everything works fine right up until I scope the package, then it all breaks. Why is it that module resolution works in |
This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes. |
Just ran into this issue, and yes it does feel like a bug. The above declared workaround Now I don't know what to do.... Will look into manual type mapping. |
May be it's folly, but my problem was in package.json. Yarn doesn't add scoped(! only scoped) packages automatically in dependencies block... In included package:
|
So this was my solution that worked: tsconfig.json: {
"compilerOptions": {
"baseUrl": "./",
// add all extra @types declarations here (including non-scoped now)
"paths": {
"@abandonware/noble": ["./@types/abandonware__noble/index.d.ts"],
"json-diff": ["./@types/json-diff/index.d.ts"],
...
},
...
} I tried Is my solution a workaround, or is this the supposed way to solve adding type declarations for scoped packages? TS Version: 3.7.4 |
I also tried |
Did my solution in #30599 (comment) work @TrueWill? |
@johanlunds No, but thank you for posting that and for following up. I tried:
All without success. I finally gave up and just To be clear, I was running into this with ts-node, so it may be specific to that tool. I'll delete my earlier comment. |
TypeScript Version: 3.4.0-dev.20190326
Search Terms:
scoped package local definition
Code
tsconfig.json
source/index.ts
types/scope__scoped/index.d.ts
types/scope__scoped/index.d.ts
tonode_modules/@types/scope__scoped/index.d.ts
node_modules/@types/scope__scoped/index.d.ts
totypes/@scope/scoped/index.d.ts
Expected behavior:
A module located in any directory referenced by
typeRoots
compiler option behaves the same, whether it is innode_modules/@types
or some other type root.Actual behavior:
When the module is in
node_modules/@types
it can be resolved via the magic rename ofscope__scoped
to@scope/scoped
. When the module is in any other typeRoot directory, it cannot be located.Playground Link:
Related Issues:
Directly related to #15204 (but that is locked).
Related to #23999 as well.
I am aware that I can resolve this specific issue by wrapping my definition file in a
declare module "@scope/scoped" { ... }
. This issue is more for tracking the fact that there is a discrepancy that is unexpected from a user's point of view. I was writing this definition in preparation for uploading to DefinitelyTyped, and to get started I copied an existing scoped module from DefinitelyTyped into my project and ran into this problem (which took me quite a while to troubleshoot/isolate since I didn't expectnode_modules/@types
to be special/magic).The text was updated successfully, but these errors were encountered: