Should deno support "declare module"?

[espindola]

The following example illustrates what is missing

test.ts:

/// <reference path="./foo.d.ts" />
import { zed } from "bar"

foo.d.ts:

declare module 'bar' {
    function zed();
}

$ npx  tsc test.ts
$ deno run --check=all --reload  test.ts
error: Relative import path "bar" not prefixed with / or ./ or ../
    at file:///home/espindola/chisel/test-declare/test.ts:2:21

code like this is fund, for example, in https://esm.sh/v86/@types/node@16.11.33/querystring.d.ts

[dsherret]

I don't think so. For that scenario the way to do it is to use @deno-types (https://deno.land/manual/typescript/types#providing-types-when-importing). Thoughts @kitsonk?

[kitsonk]

Correct. We do not generally support ambient module declarations, as the break the model of tightly coupling code to types. That being said, there is already limited support, discussed further down in manual at: https://deno.land/manual/typescript/types#using-ambient-or-global-types

[espindola]

Thanks. I will try to find how I was hitting the querystring.d.ts and how to avoid it.

[zandaqo]

For that scenario the way to do it is to use @deno-types

In front-end development, it's common for frameworks to use files with non-standard extensions (.css, .vue, .svelte) the idea often being that compilers will turn them into proper js imports of known type during the build step. Thus, during development, we can use declare module *.css to type all css imports, for example. Using @deno-types would require to prepend every import which isn't really user friendly. IMHO, the lack of declare module, or any other similarly succinct way to support this use case, unnecessarily limits Deno's usability as full stack dev platform.

[niedzielski]

I tried the approaches mentioned in the docs but couldn't seem to get them to pass the type-checker.

I couldn't get // @deno-types="./gridSVG.d.ts" or /// <reference types="./gridSVG.d.ts" /> to define a new module. Ambient module definitions, which are what I would normally use, don't seem to support wildcards in Deno. Relative pathnames work but only when declared near the import, however, then the export doesn't work.

// grid.d.ts.

// Ambient module declaration cannot specify relative module name.deno-ts(2436)
declare module './grid.svg' {
  const text: string
  export default text
}

// Some TypeScript file with the import.

import gridURI from './grid.svg'
declare module './grid.svg' {
  const text: string
  // Exports and export assignments are not permitted in module augmentations.deno-ts(2666)
  export default text
}

Neither // @ts-expect-error nor // @ts-ignore had effect either which would have been a great escape hatch.

I am currently using a gnarly async import with a cast like:

const gridURI = (<{ default: string }> await import('./grid.svg')).default

[phoenisx]

This also affects ambient imports provided by Sveltekit.

Might affect #17248

[phoenisx]

For now, for every ambient imports in sveltekit, I have to create a random import map like the following to make it work, but doesn't seem like a good solution.

{
  "imports": {
    "$env/static/private": "./.svelte-kit/ambient.d.ts"
  }
}