It seems like we'll need to add a new @types lookup feature, to align with TypeScript's @types resolution.

I don't know anything about @types lookup, I can't even figure out how it goes from @google/maps to https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/google__maps and not https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/google-maps 😅

https://github.com/microsoft/TypeScript/blob/952dfc508256fea697aacc431edb81e3f23033b5/src/compiler/moduleNameResolver.ts#L3133-L3147

It looks like hard-coded behaviour.
TL;DR:

`@types/${packageName.startsWith('@') ? packageName.slice(1).replace('/', '__') : packageName}`

I think I can get this implemented if it's trivial:

• add an option to enable @types lookup
• do the naming conversion
• do the resolution
• return an extra field for @types resolution

Is it possible to create another resolver instance with the modules option pointing to the @types directory? I think @Dunqing figure it out somehow.

Here's a similar example to resolve tsconfig.json:

Is it possible to create another resolver instance with the modules option pointing to the @types directory? I think @Dunqing figure it out somehow.

I want to confirm the scope of this instance. Just resolve @types/* packages? Or for all packages, resolve out the corresponding type declarations.

Here are the different types of packages that I have listed

// no type declarations but has @types
import { LatLng } from '@google/maps'; // resolved path: file:///node_modules/@types/google__maps/index

// type only package
import {} from 'undici-types' // resolved path: file:///node_modules/undici-types/index

// both js source files and corresponding type declarations
import { } from 'vite' // resolved path: file:///node_modules/vite/dist/node/index

// js only package
import {} from 'js-only-pacakage' // resolved nothing

If that's what we're going to do, I think we can do a lot of linter rules about .d.ts

The resolution will return both the package path as well its types packages.

I was thinking about implementing this in user land, but seems a bit difficult after a second thought.

If my understanding is correct, I think we should do this

• add an option to enable type resolution
• try to look at types and typings fields in package.json if not do the @types lookup
• do the resolution
• return an extra field for type resolution

Just being curious, are ambient modules also in the scope of this issue/package?

@Boshen, was there a resolution to this issue? Or a workaround?

@Boshen, was there a resolution to this issue? Or a workaround?

I closed this as not planned. But given your familiarly with this project, you may give this a try.