Stabilize bytes and text imports

[dsherret]

Requires a resolution of:

• Import with type text, bytes, and URL whatwg/html#9444 (https://github.com/tc39/proposal-import-bytes)
  • Immutable array buffer?

[sigmaSd]

Is this code supposed to work ?

import ptyFFI from "https://github.com/sigmaSd/deno-pty-ffi/releases/download/0.36.0/libpty_x86_64.so" with {
  type: "bytes",
};

console.log(ptyFFI);

currently it errros with

error: Expected a JavaScript or TypeScript module, but identified a Unknown module. Importing these types of modules is currently not supported.
  Specifier: https://objects.githubusercontent.com/github-production-release-asset-2e65be/661890587/9f64be92-3559-4a6f-b159-7a2e047978e9?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=releaseassetproduction%2F20250627%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20250627T223126Z&X-Amz-Expires=1800&X-Amz-Signature=f77ebdaac117bfbd1d7ab0f90d9b4581e0f7afc365975e2cf0c4a4a3bd7cbd60&X-Amz-SignedHeaders=host&response-content-disposition=attachment%3B%20filename%3Dlibpty_x86_64.so&response-content-type=application%2Foctet-stream

[marvinhagemeister]

•  type: 'text' import from npm package attempts to parse file as TS/JS #29966
•  Require --allow-read permission

[NfNitLoop]

@marvinhagemeister Regarding "Require --allow-read permission", is that only w.r.t. the related npm package imports?

The benefit of importing bytes/text modules is that they become part of the module graph so that they don't need --allow-read, right?

I'm currently working on using bytes (& maybe text) imports in NfNitLoop/deno-embedder#21 so I'd be very interested to know if the permissions requirements around that are going to change soon. 😅

[dsherret]

I don’t think we should require --allow-read for statically analyzable imports #29991

[marvinhagemeister]

I don’t think we should require --allow-read for statically analyzable imports #29991

What's the difference here? Both are statically analyzable.

await import("/etc/passwd", { with: { type: "text" } });
// vs
await Deno.readTextFile("/etc/passwd");

[NfNitLoop]

The title of this issue is currently: "Stabilize bytes and text imports".

But I was sent here by a link in an error message from deno publish --dry-run:

error[unstable-raw-import]: raw imports have not been stabilized
 --> /Users/codyc/code/deno-embedder/examples/with-embedder/browser/generated/dir.ts:4:22
  |
4 | "app.js": ()=>import("./app.js",{with:{type:"bytes"}}),
  |                      ^^^^^^^^^^ the specifier
  |
  = hint: for the time being, embed the data directly into a JavaScript file (ex. as encoded base64 text)

  docs: https://github.com/denoland/deno/issues/29904

I view these two as separate issues:

1. "Stabilize" bytes and text imports by removing the requirement to add the --unstable-raw-imports flags when running deno.
2. Allow publishing of text/bytes imports to JSR.io.

I imagine # 1 is blocked on the linked whatwg issue, which has been open for 2+ years now.

Hopefully # 2 isn't blocked on that as well? (Is it worth creating a separate tracking issue, if it's not?)

I almost feel like --unstable-raw-imports is a bit of a trap. If you use it, your packages are unable to be published to JSR.io.

[dsherret]

What's the difference here? Both are statically analyzable.

One appears in the output of deno info <entrypoint> and the other doesn't.

Allow publishing of text/bytes imports to JSR.io ... Hopefully # 2 isn't blocked on that as well?

Publishing bytes and text imports to JSR requires the feature to be stabilized. It would be really bad for the ecosystem to adopt it and then some radical changes happen and all kinds of packages break. I recommend to still embed with your deno-embedder project until stabilization.

[dsherret]

We decided to increase the permissions in #30184

Edit: And now we're going back to the way it was before: #30196

Reason is this has been an established security principle:

The initial static module graph can import local files without restrictions: All files that are imported in the initial static module graph can be imported without restrictions, so even if an explicit read permission is not granted for that file. This does not apply to any dynamic module imports.

https://docs.deno.com/runtime/fundamentals/security/#key-principles

[andykais]

👋 is there an issue we can track for when bytes imports are supported in jsr packages? I am (perhaps unwisely) going to bank on the fact that this will happen in the future, and the fact that I do not need my package published to jsr just yet while it is under development.

Previously I handrolled a lot of this by including files in my deno.json includes section, and fetching files from jsr.io directly (implementation here). That code was complicated and confusing, so I'm dropping it in favor of needing --allow-raw-imports locally, and 🤞 that we get a stabilized approach to this in the future.