You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's annoying to have to specify stuff like // @deno-types="..." /> above an import (ex. for a npm:@types/... package) and sometimes it's not possible to specify it (ex. with jsxImportSource: denoland/deno#18203).
Perhaps for any import map entry, deno_graph should try to resolve a corresponding @types/<entry-name> when resolving the types of a module. For example:
This introduces some complexities when unfurling import maps, but I don't believe it would be too bad because we could inject a // @deno-types="..." comment above the import/export.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
It's annoying to have to specify stuff like
// @deno-types="..." />
above an import (ex. for anpm:@types/...
package) and sometimes it's not possible to specify it (ex. withjsxImportSource
: denoland/deno#18203).Perhaps for any import map entry,
deno_graph
should try to resolve a corresponding@types/<entry-name>
when resolving the types of a module. For example:Then when a user imports
react
orreact/jsx-server
this would get the corresponding types.This would also not be npm specific and allow for mapping to non-npm types like:
Import map unfurling
This introduces some complexities when unfurling import maps, but I don't believe it would be too bad because we could inject a
// @deno-types="..."
comment above the import/export.The text was updated successfully, but these errors were encountered: