DefinitelyTyped / @types not automatically resolved with deno.json

[liamfd]

First off, just wanted to say thanks to everyone maintaining this project - it's been a pleasure to use.

Problem Context

In my codebase, I've found that the DX around using @types packages is a bit rough around the edges.

In practice, most of the import statements in my codebase are written by my editor's auto-importing (Cursor), which adds the import statement without the @ts-types. Deno didn't warn on these, so most of our imports wound up silently typed as any.

This is partially an editor issue, though the same editor doesn't have this issue with npm/TypeScript because they don't need the comment.

Versions

❯ deno --version
deno 2.1.4 (stable, release, aarch64-apple-darwin)
v8 13.0.245.12-rusty
typescript 5.6.2

Repro

Minimal test case here: https://github.com/liamfd/test_deno_types. I just did the deno init and then tweaked the code. More info in the repo's README.

I was also able to repro this by introducing type errors to some of the example repos. e.g. just copy pasting:

import { useEffect } from 'react';

const foo: string = useEffect; // this assignment should report a type error, but doesn't
console.log(foo);

Into this reported a type error as expected, but that same code in this did not.

Workaround

As a workaround, I have found that if I manage my npm dependencies in a package.json (and use the deno.json for everything else), and remove "nodeModulesDir": "auto" from deno.json, it behaves like npm/TypeScript, where the types are just automatically resolved. May need to rm -rf node_modules && deno install --reload as well.

With ^, deno add seems to be able to choose the right file for new deps, npm: goes in the package.json, and the rest in deno.json, which is a nice touch.

This matches the behavior of the example repos - this one has a package.json and my intentional type error worked, but this one does not use a package.json and the type error was not reported.

Minimal example of the workaround: liamfd/test_deno_types#1.

Questions

1. Just to confirm, is the intention that users add the @ts-types comment on every import for packages that don't have their types set up in a Deno-compatible way? That's what I infer from the Configuring TypeScript and Node and npm support docs, but I just want to make sure I'm not doing something dumb.
2. Is my workaround the intended behavior for Deno?
3. Is there another convention I'm missing that allows you to avoid repeating the @ts-types comment? Maybe using a mirror? I didn't see anything that looked like official releases for the packages I use from JSR/deno.land.

Suggestions

Assuming this is working as intended, here are some options that come to mind for me:

1. If my workaround (or some other convention) is the recommended way to do this, update the docs mentioned above to reference it (happy to contribute this). If not:
2. Mirror the package.json/npm's behavior for deno.json managed deps. Medium+ sized projects that use packages like React have a ton of import statements, requiring the comment on every one is a lot of overhead. (Guessing this is a no-go 😅).
3. Make the usage of the @ts-types comment a little friendlier:
   1. Update the docs mentioned above to explicitly call out the difference in behavior with npm. It's implied with the current docs, but as someone coming from the npm ecosystem, it would helped me if it were really hammered home (happy to contribute this).
   2. Add an error (either from deno lint or deno check) when importing something without the // @ts-types.
   3. Document / add a means of automatically inserting the comments. Easiest to me seems to be an autofixable deno lint rule and then encouraging users to lint on save. Maybe there's a better way to do it (e.g. leveraging lsp: quick fix for adding a // @ts-types="npm:@types/..." directive #18884)?

Please let me know if I can clarify anything. I'm happy to contribute what I can, especially docs if that's all that's needed, I just need some guidance on intended behavior/best practices. Thanks again!