Carlos Scheidegger Posts

Carlos Scheidegger

•Created by Carlos Scheidegger on 9/18/2024 in #help

`deno vendor` + `/// <reference types=...>` ?

In Deno 1.46.3, it seems that deno vendor doesn't like to see <reference types=''> entries in source code. Concretely, I can't seem to call deno vendor in any project that eventually sees https://deno.land/std@0.224.0/crypto/_wasm/lib/deno_std_wasm_crypto.generated.mjs?source=#L5, since that causes the following error:

error: Expected a JavaScript or TypeScript module, but identified a Unknown module. Importing these types of modules is currently not supported.
  Specifier: https://deno.land/std@0.224.0/crypto/_wasm/lib/deno_std_wasm_crypto.generated.d.mts
    at https://deno.land/std@0.224.0/crypto/_wasm/lib/deno_std_wasm_crypto.generated.mjs:5:22

error: Expected a JavaScript or TypeScript module, but identified a Unknown module. Importing these types of modules is currently not supported.
  Specifier: https://deno.land/std@0.224.0/crypto/_wasm/lib/deno_std_wasm_crypto.generated.d.mts
    at https://deno.land/std@0.224.0/crypto/_wasm/lib/deno_std_wasm_crypto.generated.mjs:5:22

Is that a bug?

1 replies

DDeno

•Created by Carlos Scheidegger on 9/18/2024 in #help

`deno vendor`: help with import_map.json changes from deno.land to jsr?

Hi - I'm hoping to get some guidance of best practices of migrating a (n admittedly complicated) import_map.json file from using https://deno.land/std@0.224.0 to jsr Our import map at Quarto currently contains entries like this:

    "archive/": "https://deno.land/std@0.224.0/archive/",

    "archive/": "https://deno.land/std@0.224.0/archive/",

We use this syntax because it allows us to do imports in our TS code like this: import { Tar } from "archive/tar.ts"; import { Zip } from "archive/zip.ts";, etc. This allows our import map to not worry about which of the tar.ts, zip.ts are going to be ultimately imported in our code. My specific problem is I'm having a hard time converting that to a jsr import, say

    "archive/": "jsr:@std/archive@^0.224.0/",

    "archive/": "jsr:@std/archive@^0.224.0/",

If I maintain the trailing / in the syntax, I get a failure like this when calling deno vendor:

error: Failed to resolve the specifier ""archive/tar.ts"" as its after-prefix
            portion ""tar.ts"" could not be URL-parsed relative to the URL prefix
            "jsr:@std/archive@^0.224.0/" mapped to by the prefix "archive/"

error: Failed to resolve the specifier ""archive/tar.ts"" as its after-prefix
            portion ""tar.ts"" could not be URL-parsed relative to the URL prefix
            "jsr:@std/archive@^0.224.0/" mapped to by the prefix "archive/"

But if I switch to an import_map statement like

    "archive": "jsr:@std/archive@^0.224.0",

    "archive": "jsr:@std/archive@^0.224.0",

then it seems that I need to declare each of the imports (tar, zip, etc) separately in the import map itself. That would be a big bummer and a source of ongoing maintenance toil for us, because the import_map will become much more brittle than before. Is there a way to import from jsr and retain the flexibility with paths we used to have in import maps and deno vendor? Thanks for the help!

28 replies