Closed abdessamadely closed 2 years ago
I have had the same problem for a few days now.
My investigation is that one of the node_modules didn't make it to the client-side. I tried extracting the functionality from the route main file into the xyz.client.ts
and explicitly import the nodes modules but no luck
following...
I think some node
code end-up in the client side, as Buffer available for node but not for the browser
But i can't find where's it's coming from, currently looking for a way to handle uploads with external express server
I am facing a similar error, while trying to include graphql-ws in my app.
constants.js:5 Uncaught ReferenceError: Buffer is not defined
at node_modules/ws/lib/constants.js (constants.js:5:17)
at __require2 (chunk-FDP6WGZF.js:19:44)
at node_modules/ws/lib/buffer-util.js (buffer-util.js:3:26)
at __require2 (chunk-FDP6WGZF.js:19:44)
at node_modules/ws/lib/permessage-deflate.js (permessage-deflate.js:5:20)
at __require2 (chunk-FDP6WGZF.js:19:44)
at node_modules/ws/lib/receiver.js (receiver.js:5:27)
at __require2 (chunk-FDP6WGZF.js:19:44)
at wrapper.mjs:2:22
I show a way to import the buffer
polyfill package. NOTE: it does require a patch of Remix compiler since it complains about importing package of node built-ins.
yeah I have the same problem :-( It's a difficultly of working with Remix that the app actually crashes (no JS) but still renders the html so it's not clear that it's crashed.
A solution is to bring in the unstable_...
functions that are throwing in a .server file (eg postData.server.ts
) and call this function from the action
import {
unstable_createMemoryUploadHandler,
unstable_parseMultipartFormData,
} from "remix";
const uploadHandler = unstable_createMemoryUploadHandler({
maxFileSize: 5_000_000,
});
export async function uploadAvatar(request: Request) {
const formData = await unstable_parseMultipartFormData(
request,
uploadHandler
);
const file = formData.get("file");
console.log("file in action function: ", file);
return file;
}
I have moved to Next.js for the moment as i already have some working examples of what i'm trying to do.
Please @fergusmeiklejohn if this solution is working for you, let me know so i can close this issue.
Thanks
putting the code in a server only file solves the problem but the Remix team should still be made aware of this bug. It's probably a problem the Buffer package authors need to fix
Same problem for me. Using @emotion/server/create-instance
leads to ReferenceError: Buffer is not defined
I moved on to nextjs mainly because remix doesn't have websockets connecting its node server to client.
@Shaquu I'm having roughly the same issues as well. I'm using Cloudflare Pages as my preferred Remix setup. I tried the example locally and it seems to build fine in dev mode using the @remix-run/serve
package.
I also tried to change the emotion context files to context.server.ts
and context.client.ts
to better model their documentation to see if the compiler would leave out the that code but it appears that it's not.
Hopefully that info helps others who are troubleshooting this. TBH, I tried styled-components first but ran into SSR issues and inconsistencies between the server and client generated classes. I tried shimming Linaria but there's too many unknowns with that so I came to emotion. It seems like a fully baked example but this one issue just seems to be sticky
@drewdecarme to be honest, I just removed emotion references from the code and I am going forward. It is not that important to stop me from getting to know remix.
Yeah I'm completely with you on that one. I'm fine with writing the styles I need outside the context of the component. I just love the convenience of co-locating the styles with the component which I've gotten accustomed to over the years.
Yeah I'm completely with you on that one. I'm fine with writing the styles I need outside the context of the component. I just love the convenience of co-locating the styles with the component which I've gotten accustomed to over the years.
Maybe try this one?
https://github.com/emotion-js/emotion/issues/2554#issuecomment-1066068218
Thanks a lot for the fix @fergusmeiklejohn! Do you know if it's possible to update the maxFileSize
for a custom uploadHandler
? I'm trying to allow large video file uploads, but it seems to be inheriting the default 3_000_000
from unstable_createFileUploadHandler
.
Sure you just do something like this:
const uploadHandler = unstable_createMemoryUploadHandler({
maxFileSize: 5_000_000,
});
Is anyone able to reproduce this with the latest release? We added some node browser polyfills and removed some node-specific code from the runtime package in the last few updates.
Checked on 1.3.2 and still can't use Buffer
on client.
If you just try to use Buffer on the client, it compiles but you get runtime error: ReferenceError: Buffer is not defined
If you install polyfill buffer
package, you get the error: It appears you're using a module that is built in to node, but you installed it as a dependency which could cause problems. Please remove buffer before continuing.
This is why I have the patch that removes the check for node builtins.
Hello!
I was trying to achieve the same as in the doc here https://remix.run/docs/en/v1/api/remix#unstable_createfileuploadhandler and this Buffer is not defined
error happened to me as well...
But I noticed that if instead of this:
// Code from the doc
const uploadHandler = unstable_createFileUploadHandler({
maxFileSize: 5_000_000,
file: ({ filename }) => filename,
});
export const action: ActionFunction = async ({ request }) => {
const formData = await unstable_parseMultipartFormData(
request,
uploadHandler
);
const file = formData.get('avatar');
// file is a "NodeFile" which has a similar API to "File"
// ... etc
};
you do this:
// Notice the uploadHandler being defined INSIDE the action function
export const action: ActionFunction = async ({ request }) => {
const uploadHandler = unstable_createFileUploadHandler({
maxFileSize: 5_000_000,
file: ({ filename }) => filename,
});
const formData = await unstable_parseMultipartFormData(
request,
uploadHandler
);
const file = formData.get('avatar');
// file is a "NodeFile" which has a similar API to "File"
// ... etc
};
Then the error doesn't appear anymore and the file is available with formData.get('avatar')
I just started using Remix, so not sure it's a correct approach, but maybe it's at least a step in the right direction 🙂
I actually got this error on 1.3.3 also when only using the regular formData parser like await request.formData();
in an action but downgrading to 1.3.2 fixed it.
Pretty big bug since crashes all the client side js.
~I'm also running into this error since upgrading to Remix 1.3.4. Downgrading to Remix 1.3.2 resolves the error.~
Edit:
I encountered this issue on a project built on the Remix grunge stack.
I cannot reproduce this issue in a newly initialised project. That includes a new Remix grunge stack and a new vanilla remix project.
After seeing that the error only occurs in my project, i started chopping out code. In my case the error was triggered by a Cypress test route with two imports:
import { createUser } from "~/models/user.server";
import { createUserSession } from "~/session.server";
Removing these imports was enough to avoid triggering the error.
This same code exists in the Remix grunge stack project and doesn't trigger the error, so something else may be at play here. I haven't dug any deeper yet.
Same error, but not using unstable_parseMultipartFormData
at all.
I have a very trivial example where it appears React 18 is the culprit, https://github.com/cloudflare/wrangler2/issues/754 -- not sure if anyone else has such an issue
FYI, I am working on this, but in the mean time you can either create a separate .server.js
file as mentioned before, or initialize your server code inside your loader or action instead of the top-level scope of the route module.
I spoke with @jacob-ebey about this and the problem ultimately is our documentation. When you call a function in the top-level scope of your route module, our compiler can't reliably code-split that bit from the browser build. And while we do shim Node built-ins, we don't shim Node globals and would prefer that Buffer
not end up in your browser build at all.
So to solve this, you have two options:
*.server.js
file that wraps your server handlers so that our compiler can reliably remove it from the browser, as documented hereInitialize the handler inside your loader or action instead of the root level, as we already remove those exports from the browser build
// instead of this...
let uploadHandler = unstable_createFileUploadHandler({
maxFileSize: 5_000_000,
file: ({ filename }) => filename,
});
export async function action({ request }) {
let formData = await unstable_parseMultipartFormData(request, uploadHandler);
// ...
};
// do this...
export async function action({ request }) {
let uploadHandler = unstable_createFileUploadHandler({
maxFileSize: 5_000_000,
file: ({ filename }) => filename,
});
let formData = await unstable_parseMultipartFormData(request, uploadHandler);
// ...
};
Understand that unstable_createFileUploadHandler
is the example, but this "gotcha" would generally apply to any functions you might call in a route. Functions called at the top-level or the Route component will be included in both bundles, functions called in actions/loaders will only be in the server bundle.
In the meantime, I'll make sure all of our examples and documentation are updated to fix any bugs and clarify!
@chaance
i dont get it: why the same route code, migrating to react18 + latest remix throws the error? I’m not using any unstable_parseMultipartFormData
as i posted early.
@chaance
i dont get it: why the same route code, migrating to react18 + latest remix throws the error? I’m not using any
unstable_parseMultipartFormData
as i posted early.
I'm unsure how React 18 specifically would cause an issue like this, but this isn't just about unstable_parseMultipartFormData
, it's about any code that should only be in your server bundle.
If you can create a new issue with a minimal repro showing your problem with React 18 we can try to help out there.
@chaance Unfortunately, I'm still getting the same issues when trying to follow the emotion example in the examples directory for Remix. I've tried a few of the fixes that you have mentioned before but still experiencing the
ReferenceError: Buffer is not defined
I would assume that the culprit is @emotion/server/create-instance/dist/emotion-server-create-instance.cjs.dev.js
and it's getting bundled in the code. It's strange since this is being called in the entry.server.tsx
file so I'd wonder if you would have any guidance based upon how the example is setup in the docs at the moment?
For what it's worth, I'm using Cloudflare Pages and am currently using Remix 1.4.1
for me what worked was:
import { defineConfig } from 'vite' import vue from '@vitejs/plugin-vue' import path from 'path' import inject from '@rollup/plugin-inject'
export default defineConfig({
plugins: [vue()],
resolve: {
alias: {
'@': path.resolve(__dirname, 'src'),
}
},
build: {
rollupOptions: {
plugins: [inject({ Buffer: ['buffer', 'Buffer'] })],
},
},
})
reply to this comment:
https://github.com/vitejs/vite/discussions/2785#discussioncomment-1452855
I'd like to point out that if you're a dummy like me, and googling Uncaught ReferenceError: Buffer is not defined
brought you here while setting up WebSockets in the Remix client. You might have done this:
// ws.client.ts
import WebSocket from 'ws';
const ws = new WebSocket('ws://localhost: 3000');
Turns out WebSocket
is native to modern browsers, so you really just need to omit the import and you're good to go
I hope this helps at least one other dev out there!
Use this on the page or function where you get an error:
window.Buffer = window.Buffer || require("buffer").Buffer;
Thank you @mhmdunl1, your solution helped me :)
Hey folks, check my example to fix this issue https://gist.github.com/jdnichollsc/b73eca1f34bdd1e3a95283774fda2212
What version of Remix are you using?
v1.2.3
Steps to Reproduce
The examples in the docs https://remix.run/docs/en/v1/api/remix#uploadhandler
Just after adding this code inside a route
Expected Behavior
To work, as expected from the docs
Actual Behavior
Log the error to the the browser console on page load