Support `import foo from "./bar.txt" with { as: "bytes" }`

[lucacasonato]

Would import the relevant file as a byte buffer (Uint8Array). Maybe also import foo from "./bar.txt" with { as: "text" }?

[marvinhagemeister]

The import as text could also be very useful for bundler plugins.

[lucacasonato]

Also see https://github.com/whatwg/html/issues/9444

[littledivy]

Would be super useful for deno compile apps (https://github.com/denoland/deno/issues/17994)

[kriskowal]

Consider immutable ArrayBuffer and spelling import uint8array from 'octets.bin' with { type: 'bytes' } to line up with type: 'json': https://github.com/tc39/proposal-immutable-arraybuffer

[maliknajjar]

this feature is essential to what Im doing because Im trying to import some assets from a JSR package I published Im sure its important for most library and frameworks authors

[pomdtr]

I would use this feature a ton for app distribution in smallweb.

[maliknajjar]

thanks to @lucacasonato for the suggested feature

for anyone who needs a temporary solution untill this feature is implemented. you can embed the content of the static files in a json file. and import it as a json like this

    const res = await import("./files.json", {
      with: {
        type: "json",
      },
    });
    const content = res.default;

and the content of the files.json file may look something like this

{
  "Counter.js": "content...",
  "NewCounter.js": "content...",
  "style.css": "content..."
}

you can even embedd binary files by converting its content to base64 string

its an ugly solution but this is what we have for now as library creators

[pomdtr]

Another alternative (based on deno-embedder): https://jsr.io/@smallweb/embed

[pomdtr]

Found a new way to reference static assets from a jsr package using the newly released jsr support in https://github.com/esm-dev/esm.sh

See https://jsr.io/@smallweb/excalidraw/0.9.0/pkg/server.ts#L56

Basically, if the package was imported from an url, the static assets are fetch from raw.esm.sh instead of being read them from the filesystem.

[andykais]

just throwing my 2c in on this issue, I'd like to see us be able to tell jsr which assets to download and have those be written to a folder by deno. Imo this is the most ideal workflow. We already have plenty of ways to bundle assets in a way that we can read in memory (see the above message). The issue is that most workflows are tied to the filesystem already, so its an extra step to massage in memory asset data back into something that can be used by the system. For instance, if I have a local web application that has asset data (like I do with jsr.io/@forager/web) then I need to add a build step to bundle those into something I can import into typescript, then massage those back into files, and then store those files on disk somewhere so that my application serve those, all during startup. This requires both --read and --write permissions, and likely --allow-env permissions as well to find a good directory to cache files. Imo, the most ideal situation is if deno can handle downloading asset files somewhere, and then we can see the filepath/folder for those assets. Something like:

{
{
  "name": "@forager/web",
  "version": "0.0.13",

  "exports": {
    ".": "./mod.ts",
    "./config": "./config.ts"
  },

  "publish": {
    "include": [
      "README.md",
      "LICENSE",
      "mod.ts",
      "config.ts",
      "server.js",
      {"files": "static/**/*", "download": true},
      {"files": "server/**/*", "download": true}
    ]
  }
}
}

which can then be referenced in code:

// mod.ts
import * as path from '@std/path'

const static_assets = path.join(import.meta.dirname, 'static')
const bundled_js = path.join(import.meta.dirname, 'server')
// now we can tell the server to serve files from these folders

[iuioiua]

It'd probably be worth deprecating Deno.readFile[Sync] and Deno.readTextFile[Sync] in favour of these new approaches at some point, once implemented.

[bartlomieju]

Importing a binary blob is not a replacement for reading a file from disk - imports stay in memory forever, if you wish to load a file, process it and then reclaim the memory imports will not work for this use case.

[iuioiua]

Oh... Didn't consider that.

[jollytoad]

jsr will need to provide a way to export assets too... https://github.com/jsr-io/jsr/issues/987

[xbwwj]

This feature is also important for writing WGSL shaders.

Is there any PR working on this yet?

[jerry4718]

This feature is also important for writing WGSL shaders.

Is there any PR working on this yet?

here we can probably see some cause and effect https://github.com/denoland/deno_core/pull/1025

[KnorpelSenf]

Are you planning on adding support for this to JSR?

[bartlomieju]

@KnorpelSenf yes, once https://github.com/tc39/proposal-import-bytes reaches later stages and we'll be sure that there will be no changes in semantics, we will stabilize it and add support for JSR.

[KnorpelSenf]

Amazing, thanks!