nfnitloop / deno-embedder Goto Github PK

deno-embedder creates files that depend on embed.ts, relative to the place that deno-embedder was imported, using import.meta. But it looks like import.meta exposes JSR imports as HTTP imports, which breaks deno check, which gives an error like this:

> deno task check
Task check deno check src/main.ts
error: Failed resolving types. Importing JSR packages via HTTPS specifiers for type checking is not supported for performance reasons. If you would like types, import via a `jsr:` specifier instead or else use a non-statically analyzable dynamic import.
  Importing: https://jsr.io/@nfnitloop/deno-embedder/1.3.0/embed.ts
    at file:///[...]/src/generated/static/dir.ts:1:17

• No spaces in filenames.
• Filenames may not contain .d.ts, even in the middle.

Add some normalization to the file names generated by deno-embedder so that they don't run into these issues.

This is a feature I requested and used in rust-embed: pyrossh/rust-embed#140

Would be nice to have it here too.

• Update the generator to save LastModified
• Update the generator (or just ad a lazy method) to provide a sha-256 hash of the bytes.
• Update the oak helpers to properly serve requests w.r.t. Tag/Last-Modified

Right now I just point to the sample repo.

While it does have a lot of comments to help guide users, a proper README guiding through setup would be better. :)

ESBuild was easy to set up as a plugin, but it currently has a bug/limitation that re-exports (which are a recommended pattern in Deno deps.ts files) aren't properly removed by tree-shaking.

Add support for Webpack and/or Rollup to support better tree-shaking.

Additionally:

• One of those might let me specify whether/how to chunk external dependencies?

A main function is exported from mod.ts, but is never run.

As a proof of concept, I created a simple CLI script that wraps the main function.

Proof-of-concept: https://github.com/ethanthatonekid/deno-embedder-cli#readme

deno run -A https://deno.land/x/embedder_cli/main.ts --mappings="[{\"sourceDir\":\"./.vscode\",\"destDir\":\"./examples/00_vscode\"}]"

As part of a build, it would be nice to be able to re-generate embedded files to make sure they're the most up-to-date versions. (that is: without starting up "dev mode" and then having to kill that server.)

Preferably, there would be an option to also just check that the generated files and return an error if they're not up-to-date.

Hono has replaced oak as the go-to http router for deno.

A middleware would be nice. The built-in static middleware can probably be easily adapted:

https://jsr.io/@hono/hono/4.4.7/src/middleware/serve-static/index.ts

The current implementation of Deno Embedder creates a dir.ts file which imports all files for an embed directory.

This means that if you have a large set of embeds, you pay the cost of loading all of those embeds every time you start your application, even if you're not going to use them all.

It would be great if we could create a files list like:

const files = {
  "Smiley.svg": () => import("./Smiley.svg_.ts"),
  "index.html": () => import("./index.html_.ts"),
} as const

That way, we'd only need to import one of the embedded files if it's requested.

Blockers

I thought this new feature would allow using dynamic imports:
https://deno.com/blog/v1.32#deno-compile-support-for-web-workers-and-dynamic-import

However, the current implementation seems limited to binaries built with deno compile.

• ✅ deno compile has access to all dynamic imports without requiring additional permissions.
• ❌ deno install does not install dynamic imports, and they must be imported from network/disk, by granting extra permissions to do so.
• ❌ deno run also requires extra permissions to load dynamic imports. (This impacts "dev mode".)

My goal for Deno Embedder is for it to "just work" for all these cases, so I'm not going to bother supporting dynamic imports until Deno supports the above cases.

Upstream tracking issues:

• denoland/deno#17697
• denoland/deno#18514

Error message:

Unknown export './src/embed.ts' for '@nfnitloop/[email protected]'.

1.4.7 works fine.

See: https://docs.github.com/en/repositories/working-with-files/managing-files/customizing-how-changed-files-appear-on-github

Since v1.2.1, I switched to using https://github.com/lucacasonato/esbuild_deno_loader to download/cache Deno dependencies.

However, that plugin has an issue bundling non-code sources:

• lucacasonato/esbuild_deno_loader#129

Workaround:

Until then, keep code and non-code assets in separate directories (like in the example), and disable the bundleRemoteSources option if you need to use the ESBuild plugin on non-script resources.

Probably just use https://github.com/lucacasonato/esbuild_deno_loader instead of my own implementation.