-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Try to get oak running under dnt #14
Comments
@dsherret I took the first stab at this on https://github.com/oakserver/oak/tree/node I added |
Current diagnostics in latest main (sorry, I meant to do a release yesterday that would have fixed a ton of the diagnostics):
|
Opened deno.ns issues:
Opened dnt issues:
Not sure how to solve and I'll need to look into it more later (kind of lazy at the moment):
Looks like a bug in std. I don't see these exports (edit: maybe I didn't look hard enough... I see them know):
|
Current diagnostics:
Using my local dnt right now as it has the crypto fixes: import { build } from "../../dnt/mod.ts";
await build({
entryPoints: ["./mod.ts"],
outDir: "./npm",
shims: {
deno: true,
timers: true,
},
package: {
// package.json properties
name: "oak",
version: Deno.args[0],
description: "Your package.",
license: "MIT",
repository: {
type: "git",
url: "git+https://github.com/username/package.git",
},
bugs: {
url: "https://github.com/username/package/issues",
},
},
});
// post build steps
Deno.copyFileSync("LICENSE", "npm/LICENSE");
Deno.copyFileSync("README.md", "npm/README.md"); Issues: |
The first two diagnostics, are strange to say at least. I wonder why we don't these problems in |
@bartlomieju it is what happens when not targeting ESNext ☹. I may write a transform to handle it, but I'm not sure. Current diagnostics (using node-fetch and I have some upcoming fixes for dnt):
|
You can target non-ESNext but use the esnext lib? |
I opened denoland/std#1917 to work around the limitation of the I've worked around the other type issues in oak itself, so it is almost passing type checking, I am starting getting the Node.js abstraction in for handling requests. |
Ok, with denoland/std#1917 merged my branch now builds, but fails on the tests... Now I've run into a more fundamental issue @dsherret. Is there any way to get dnt to emit ESM modules instead of CommonJS? The problem is that you can only use TLA in ESM modules and in order to make it work, I need to optionally import some stuff using dynamic import at the top level. For example, I have a utility class of const TransformStream = globalThis.TransformStream ?? (await import("stream/web")).TransformStream; But that requires TLA... I suspect there will be a lot of other minor problems as well, it seems like the default target for dnt for Deno code should really be ESM and make the package an ESM package, but have an escape hatch to convert it to CommonJS, but most Deno code should work better under emitted as ESM and already has dependencies that are ESM only. |
Ok, looks like I can skip CommonJS and UMD output, so I think I might be ok, just more configuring on the build script. |
Closed by oakserver/oak#479 |
@kitsonk thank you so much for the hours of research you put on this! |
The only thing that is valid for dnt from the approach to oak is the shimming of |
@kitsonk I do the same path as you with shimming the streams globally to make it work on Cloudflare workers, dnt doesn't work for that case. |
No description provided.
The text was updated successfully, but these errors were encountered: