Skip to content
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

Dynamic routes on Cloudflare fail trying to import node:fs/promises #871

Closed
rmarscher opened this issue Sep 10, 2024 · 3 comments · Fixed by #874
Closed

Dynamic routes on Cloudflare fail trying to import node:fs/promises #871

rmarscher opened this issue Sep 10, 2024 · 3 comments · Fixed by #874

Comments

@rmarscher
Copy link
Contributor

rmarscher commented Sep 10, 2024

The error in the workerd console is

Cannot process SSR Error: No such module "node:fs/promises".
    at null.<anonymous> (file:///waku-project/.wrangler/tmp/pages-tQnVbB/entries.js:485:11)

That is referencing these changed lines in #860. Before that PR, Cloudflare workerd must have been getting routing information from unstable_buildConfig[0].customData.data.

To reproduce
npm create waku@0.9.3
cd waku-project
npm install

Then edit src/pages/about.tsx and change getConfig to dynamic:

export const getConfig = async () => {
  return {
    render: 'dynamic',
  };
};

Clone the waku repo.
cd packages/waku
pnpm i
pnpm run compile

Copy or link the built package to the waku project. I just replace the dist folder in node_modules/waku/dist.

In the waku project, run a cloudflare build and run a local workerd server via wrangler to serve the built files locally.

npm run build -- --with-cloudflare
npx wrangler pages dev dist

open http://localhost:8788/about in your browser.

@tylersayshi
Copy link
Contributor

For this we could definitely add logic into the fs-router and build process for --with-cloudflare to polyfill fs when dynamic routes are present.

I'll defer to @dai-shi on whether or not that's an ideal approach or not with this though. I haven't looked into the plugins a ton, but maybe this would be considered a responsibility of a cloudflare plugin.

@rmarscher
Copy link
Contributor Author

Thanks for giving it a look. I'm not sure polyfilling fs is necessary... it seems the platformObject.buildData.fsRouterFiles should be populated. If the build process could pass the fsRouterFiles to the build output vite plugin, it could write to a source file during build that can be imported at runtime and added to the platformObject via the platform server.

For example, the platformObject here - https://github.com/dai-shi/waku/blob/main/packages/waku/src/lib/plugins/vite-plugin-deploy-cloudflare.ts#L86 - would need buildData.fsRouterFiles to be set. It could serialize that to a json file in the worker code bundle. That json file would be imported and passed to the waku server here https://github.com/dai-shi/waku/blob/main/packages/waku/src/lib/builder/serve-cloudflare.ts#L36-L38

@dai-shi
Copy link
Owner

dai-shi commented Sep 12, 2024

Thanks for the catch. I'll have a look.

dai-shi added a commit that referenced this issue Sep 12, 2024
close #871 

I would like to avoid depending on `globalThis`, but this is an easy fix
for now.
dai-shi pushed a commit that referenced this issue Sep 18, 2024
This (along with the previous #874) resolves the issue in #871. The
build config was being written to the wrong location for cloudflare
pages This PR exports a function from the build module that appends the
build config to the given entries file location. It uses a new unstable
build config state variable (`unstable_buildConfigSave`) to track
whether or not the build config has be saved to the entries file. This
allows the cloudflare deploy plugin to write the build config into the
worker function directory instead of the root.

We could merge #879 and then I can edit the base branch to main and
continue with this PR. Or however you want to handle it. Thank you!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants