-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
feat(templates/cloudflare-workers): update to ESM #4198
Conversation
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jacob-ebey Do we need these updates for the cloudflare-pages
template as well?
name: 🕊 Deploy | ||
steps: | ||
- name: 🛑 Cancel Previous Runs | ||
uses: styfle/cancel-workflow-action@0.9.1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Latest version is 0.10.0
uses: styfle/cancel-workflow-action@0.9.1 | |
uses: styfle/cancel-workflow-action@0.10.0 |
@@ -1,4 +1,4 @@ | |||
import type { EntryContext } from "@remix-run/cloudflare"; | |||
import { type EntryContext } from "@remix-run/cloudflare"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's keep the type at the beginning of the import to keep it consistent with the rest of the codebase
import { type EntryContext } from "@remix-run/cloudflare"; | |
import type { EntryContext } from "@remix-run/cloudflare"; |
@@ -0,0 +1,9 @@ | |||
declare module "remix-build" { | |||
import { type ServerBuild } from "@remix-run/cloudflare"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
import { type ServerBuild } from "@remix-run/cloudflare"; | |
import type { ServerBuild } from "@remix-run/cloudflare"; |
"dev:miniflare": "cross-env NODE_ENV=development miniflare ./build/index.js --watch", | ||
"dev": "remix build && run-p \"dev:*\"", | ||
"start": "cross-env NODE_ENV=production miniflare ./build/index.js" | ||
"dev": "npm run build && concurrently \"npm:dev:remix\" \"npm:dev:cloudflare\"", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're using npm-run-all
in all other templates/examples, so maybe we should use that here as well to keep it consistent?
"@remix-run/cloudflare": "*", | ||
"@remix-run/cloudflare-workers": "*", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it intentional that we're not downloading @remix-run/cloudflare-workers
by default anymore?
// appDirectory: "app", | ||
// assetsBuildDirectory: "public/build", | ||
// serverBuildPath: "build/index.js", | ||
// publicPath: "/build/", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We keep this commented out for convenience in our other templates, so maybe we should keep them here as well?
const path = require("path"); | ||
|
||
function main({ rootDirectory }) { | ||
const examplePath = path.resolve(rootDirectory, "wrangler.example.toml"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it intentional to keep this file in the root?
We keep remix.init
files in the same folder in our stacks.
@@ -0,0 +1,5 @@ | |||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can just delete this file if we don't have any dependencies
@@ -1,5 +1,5 @@ | |||
{ | |||
"include": ["remix.env.d.ts", "**/*.ts", "**/*.tsx"], | |||
"include": ["**/*.d.ts", "**/*.ts", "**/*.tsx"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mcansh Does this have implications for the convert-to-javascript
migration?
@@ -1,3 +1,2 @@ | |||
/// <reference types="@remix-run/dev" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we move this file to a types
folder as well in our other templates, so this is consistent?
This adds a lot of boilerplate. Has the Remix team considered updating |
Yeah, that seems closer to what I’d expect & it feels (very subjectively) more idiomatic. The reason this PR removes the dependency on I suspect it would be easier for end users to understand & upgrade if they only had to make a small change to their import { createEventHandler } from "@remix-run/cloudflare-workers";
import * as build from "../build";
const handler = createEventHandler({ build })
export default {
fetch(request, env, context) {
const event = { request, env, waitUntil: context.waitUntil.bind(waitUntil) };
return handler(event);
}
} |
@MichaelDeBoey @jacob-ebey Any update on which direction we want to take here? We would love to be able to switch from Cloudflare pages to workers, but this is blocking us |
I just wanted to mention that I just pulled down this branch and checked locally on a wrangler project and this PR does seem to work in its current state (compared to #1207 which has a few bits not fully working) @MichaelDeBoey @jacob-ebey could we get this PR merged soon even if some small things can be improved and iterate over those details afterwards? (so that devs using Cloudflare workers can at least start using the ESM version sooner) |
{ | ||
request, | ||
waitUntil(promise) { | ||
return ctx.waitUntil(promise); | ||
}, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Double-check if you're on @cloudflare/kv-asset-handler@0.2.0
, I had the error locally but it turned out I hadn't upgraded the package properly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's fixed it, sorry that's my bad, thanks 🙂
@dario-piotrowicz FWIW this is just a change to the Workers template, not any of Remix's actual code. Remix is fully compatible with Workers today, users just need to copy the code in this template into their setups. However, that requires a pretty specific setup. Users need to be wary of where their IMHO, as I said above, this is a very brittle approach to solving this problem & doesn't feel in line with the high standards both Remix & Cloudflare tend to aspire to for developer experience. And it would leave significant fragmentation in the Remix DX for users, because the instructions for integrating with ESM vs CJS would end up being very different--much more different than changing between Pages & Workers Sites, which is as simple as updating Again, the preferable solution would be to update the
I really want to stress how unusable this PR would be in its current state & how much additional support load it will create for Cloudflare & Remix. I'm in a busy period rn but would gladly do this properly once I'm through that. |
@huw thanks so very much for the nice clarification, yeah I understand that it is only template changes, but this is not at all straightforward to get done without checking out this PR, that's why I was asking to include it so to reduce the barrier to entry (maybe it could be added in a README, docs or something?) Anyways I had no idea that this was brittle/using a deprecated flag, I thought that the only downside of this solution was the amount of boilerplate needed. Based on what you said I agree that adding something half-baked in at this stage would make things worse rather than better.... Thanks for taking the time to look at this, I'll patiently wait for you to have more time to look into this then 🙂 Also, I don't have much knowledge on how Remix works under the hook, but if you think I could be of any help here please let me know 🙏 |
"baseUrl": ".", | ||
"paths": { | ||
"~/*": ["./app/*"] | ||
"~/*": ["./app/*"], | ||
"remix-build": ["./build/index.mjs"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this be:
"remix-build": ["./build/index.mjs"] | |
"remix-build": ["./public/build/index.mjs"] |
?
@jacob-ebey @huw @dario-piotrowicz I'm wondering if you could obtain the same result with the new config properties that were exposed by #4841 🤔 |
Closes: #764
Testing Strategy: