Ship a @remix-run/deno-deploy package?

[aaronadamsCA]

@remix-run/deno lives on NPM, but is "not an NPM package":

remix/packages/remix-deno/.empty.js

Lines 4 to 5 in ea19c12

	This package should not be bundled by Rollup as its source
	code is a Deno module, not an NPM package.

Unfortunately this makes "hello world" on Deno Deploy a lot harder than it needs to be, IMO. I don't think I actually need a Deno module, just an NPM package like @remix-run/cloudflare-workers, but for Deno Deploy.

One concrete problem with the Deno module is TypeScript checks. We will not use the Deno CLI to lint or type check; we do this ourselves in our monorepo root. But import type { MetaFunction } from "@remix-run/deno" causes errors when we run tsc:

Error: node_modules/@remix-run/deno/index.ts(2,42): error TS2691: An import path cannot end with a '.ts' extension. Consider importing './sessions/fileStorage.js' instead.
Error: node_modules/@remix-run/deno/index.ts(7,8): error TS2691: An import path cannot end with a '.ts' extension. Consider importing './server.js' instead.
Error: node_modules/@remix-run/deno/index.ts(14,8): error TS2691: An import path cannot end with a '.ts' extension. Consider importing './implementations.js' instead.

If there are .ts files in node_modules/, and you import from them, then they are considered part of your program, and must follow your rules (skipLibCheck has no effect on .ts files, only .d.ts files). This isn't great!

In our case, we worked around these issues by importing types from @remix-run/server-runtime instead of @remix-run/deno, and changing our server.ts to server.js to avoid type checks.

But I can't help wondering if there's a better way to do this: could @remix-run/deno remain a Deno module that hides Deno platform concerns, while a regular @remix-run/deno-deploy package exposes the parts Remix actually needs, with normal exports and type safety?

I am new to this, and I might be missing some things; I just wanted to provide the early feedback that this was a struggle struggle to get to "hello world", and I would love to see Deno Deploy as easy to start with as, say, Cloudflare Workers.

[MichaelDeBoey]

I once had the idea of shipping @remix-run/deno-deploy separately (see #3528), but for the reasons @pcattori explained the team decided to not do that.

[aaronadamsCA]

@pcattori, is there any chance you'd reconsider, given this additional information?

As opposed to #3528, I think what I'm suggesting is a @remix-run/deno-deploy package that is bundled with Rollup. It would adapt a Deno module to an NPM package, which IMO is just as important as adapting request/response interfaces.

I do have this working on our end now, but a reduced learning curve (like being able to import types from our adapter package) would still be a nice gain, and could reduce startup difficulty for others (again, though, I admit I could be missing something here).

[pcattori]

Wouldn't "adapting" Deno modules to an NPM package be useful for any Remix + Deno project, not just Deno Deploy-based ones? Or am I misunderstanding what you mean by "adapt"?

[aaronadamsCA]

I'm not sure! I figured there was probably a good reason for the Deno package to ship uncompiled TypeScript, and probably people who wanted to consume it that way; whereas we're just shipping JS builds to Deno Deploy. I figured it was two different use cases needing two different solutions. Can't say for sure, though.

[pcattori]

Deploying Deno modules written in TS is standard for Deno Deploy. We happen to use NPM as the distribution mechanism for our @remix-run/deno package, but we could have used https://deno.land/x instead.

It sounds like you are opting out of Deno's built-in typechecking and using tsc instead and that you want a Node package rather than a Deno module. Are you still using deno to run your app? Or are you using node?

[aaronadamsCA]

It sounds like you are opting out of Deno's built-in typechecking and using tsc instead and that you want a Node package rather than a Deno module.

That's right. What we're really trying to do, is opt out of Deno altogether, and just use Deno Deploy as our edge host.

In theory, this seemed like it would work just fine; our dev environment may be Node.js, but our build is pure JS.

In practice, though, Deno Deploy requires Deno in multiple places. I was thinking Remix could maybe hide these concerns, but I don't think so anymore, which is why we're just looking at moving to Cloudflare Workers instead.

Are you still using deno to run your app? Or are you using node?

We are still using Deno to run the app, which seems correct, since we want our dev and prod environments matching as closely as possible.