Use dtsGen to generate declaration files for imported modules with no declarations

[dannycochran]

Search Terms

dts-gen
third party modules
fallback
typings
modules without typings

Suggestion

One of the biggest concerns I've heard from new users using TypeScript is dealing with libraries that have no typings provided (neither in the library itself nor in DefinitelyTyped). In a strict TS environment or with noImplicitAny: true, TypeScript will complain about a library you import that has no associated typings definition.

Your options at this point are to provide your own typings file in a local typings folder, or use dts-gen to generate one for you.

Personally, I find this to be a useful exercise but newer users get tripped up on it and frequently cite it as one of the harder parts about TS adoption.

I had considered creating a library (similar to https://.com/tamayika/types-local) that would use dts-gen to automatically put index.d.ts files inside of libraries within your node_modules folder that have no associated typings, provided you've imported the library in your code. This would probably end up being gross and an npm anti-pattern.

Instead, it would be nice if the compiler could do this for us. If you have imported code w/o typings, the TS compiler could use dts-gen to generate typings (which obviously are imperfect) which would allow folks to proceed without worrying immediately about whether the library has typings.

Maybe a flag called dtsGenFallback under compilerOptions could do this?

Use Cases

Described above

Examples

Described above

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript / JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. new expression-level syntax)

[mhegazy]

I do not think the compiler is the right place for this feature. the language service, however, is. This is a feature that you do not do on every build, nor should it. it is rather one that you do once when you first import a package.

[dannycochran]

@mhegazy thank you for the quick response and triaging!

That makes sense that it would be under the language service. I think the only thing you'd need to check for on build is if the package updated, as an updated package may now have typings associated with it, or the output from dts-gen could be different.

To clarify though, how would you imagine users activating this feature?

[mhegazy]

I think the only thing you'd need to check for on build is if the package updated,

that is a general problem that we have today as well with the quick fix to install @types packages. Today we install the latest @types package regardless. ideally we would be more cognizant of the version and install the right version. Then the next problem is detecting version mismatches and warning the user about them, giving them the option to update. I think this feature would follow the same pattern.

how would you imagine users activating this feature?

If a module has no declaration file in it, no matching @types package in the registry, and no ambient module declaration, the user will get a Suggestion diagnostic (three little dots under the name in VSCode), along with a light pulp to create the declaration file for the missing package.

[dannycochran]

If a module has no declaration file in it, no matching @types package in the registry, and no ambient module declaration, the user will get a Suggestion diagnostic (three little dots under the name in VSCode), along with a light pulp to create the declaration file for the missing package.

Gotcha. I like that as it forces the user to understand what's happening, and that the typings are going to be very lax (dts-gen tends to do a lot of any typing).

Where would the declaration file go? I suppose you could put it into node_modules/<untypedPackage>/index.d.ts, but then it doesn't get checked in.

If you put it into the app directory, you'd probably want to check if there's already a local typings folder for untyped packages or for augmented third party typings. Determining where that existing folder lives is probably non-obvious.. I suppose you could scan compilerOptions.typeRoots and look for a local typings folder?

Separately, if a user has no local typings folder, you'd have to create one for them and modify their compilerOptions.typeRoots. Not sure the language service can do that?

[mhegazy]

Where would the declaration file go? I suppose you could put it into node_modules//index.d.ts, but then it doesn't get checked in.

node_modules is not the best place. since that is not checked in your project. we will have to pick a name for a folder for these packages. I think we can use typeRoots as a way of inferring the location of types.

[dannycochran]

@Andy-MS thanks for working on this! I noticed you marked the issue as fixed, but in the PR it says the functionality is not yet exposed to consumers? I just tried testing in 3.1 and didn't see a code fix lightbulb.