Repository navigation
"types" field in package.json pointing to a .ts file in node_modules results in the file being compiled and type checked #35744
Description
Activity
- changed the title
[-]Discovering .ts files under node_modules resulting in them being compiled and type checked[/-][+]"types" field in package.json pointing to a `.ts` file in node_modules results in the file being compiled and type checked[/+]on Dec 18, 2019 By the way, when making things like class-factory mixins and then trying to emit declaration files we get problems like described in #23110.
If we can't have implicit return types, etc, in declaration files, and we shouldn't point
"types"to.tssource files, then what should we do?How can all features of TS be somehow supported in declaration files?
Maybe implicit return types could look like this:
export declare function AwesomeMixin<T extends Constructor>(Base: T) { type Foo = SomeOtherType<T> // only types allowed in here. // only special return statements allowed, or something. return declare class Awesome extends Base { method(): Foo } }
where there's no implementation. It looks like an implementation being inside the
{}, but maybe it is limited to containing only types and return types, or something similar. We'd just need to define the rules.Reacted by Nickolay Platonov and Peter MattaFeature request: allow
typesfield ofpackage.jsonto point to a source.tsfile, then prevent the compiler from type checking the internals, just use those files for type information as it relates to consumption. Should I open a new issue for it specifically?Reacted by Nickolay Platonov and Archimedes TrajanoSheetal Nandi (@sheetalkamat) You recently merged #32028. Does that issue mean we can close this one? Can you also check my comments in that PR?
Based on #40431 (comment) by Ryan Cavanaugh (@RyanCavanaugh), that PR #32028 compiles to
.d.tsfiles in memory, then relies on those virtual declaration files.If so, I think that can be the solution for this issue if it isn't already.
Basically tsc would look at
typesinpackage.jsonthen generate the.d.tsfor that in memory instead of using source files. Wdyt?Basically tsc would look at
typesinpackage.jsonthen generate the.d.tsfor that in memory instead of using source files. Wdyt?There's only one problem with this idea: all the issues listed in #35822 will happen, and cause errors regarding "private name", etc.
Continuing from #22228
cc Sergei Dorogin (@evil-shrike)
I have this issue.
Mohamed Hegazy (@mhegazy) said
But features like inferred return types (f.e. when making class-factory mixins) are not compilable to declaration files, resulting in errors like
Not entirely true.
As far as I know, the only way to use features (that declaration files don't support) in downstream projects is to get types directly from
.tssource files. This makes the need to pointtypesto.tssource files a valid use case.This is what I think should happen:
If
"types"points to a.tsfile, and"main"points to a.jsfile, then the compiler should use the.tsfile only for type definitions and not compile or type-check the code."main"can serve as a guide to telling the compiler whether it should compile sources, or read js files."types"should be for... specifying the source of types.Unless I missed it, there's no other way to include types for features that aren't representable in declaration files.
Why is it that declaration features don't match source features? It seems that an important goal should be for declaration features to always have the capability of matching source features.