Gatsby: Is it possible for Gatsby to define browser globals during the rendering process?

[jharrilim]

Summary

Currently, code that uses browser globals or anything related to the window object break during production/SSR builds in Gatsby. There are a bunch of other issues related to this.

Would it be possible for Gatsby to handle this by any means? Perhaps it would be possible to alleviate the issue by leveraging jsdom like the way Jest does. I would like to hear your thoughts around this and how it can possibly handle window, or if not possible, why?

[jennasalau]

I'm literally looking at this too! Almost wish Gatsby just renders as a SPA instead or gave us the option.

For us we have lots of web-component classes that extend HTMLElement which naturally doesn't exist on node. During the last 2 weeks none of us actually tried a build. Apparent now all our hardwork will never build on Gatsby. Looking into Next.js now.

[joeynimu]

This would be a good one. There are lots of issues related to this. I am also using a library that uses window.customEvent and I am stuck at fixing this for it's not so apparent to me.

[ghost]

Yep, definitely need something to handle the window issues. I can only perform production builds if I wrap the libraries triggering errors with if (type of(window) !== undefined)

[gatsbot[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contributefor more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[gatsbot[bot]]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.

Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community!

[amimas]

Can this be reopened? It'd be really helpful if Gatsby could natively handle consumption of webcomponents. I'm trying to follow this doc but haven't been successful yet following the workarounds:

https://www.gatsbyjs.org/docs/using-client-side-only-packages/

[adonig]

I ran into this issue when I had to use Base64 encoding, because my image handler wants me to pass the JSON request as part of the url. Most browsers come with a global btoa function but Node.js doesn't, so the build fails. First I tried to write my own btoa function using Node's Buffer class, but it increases the bundle size by 6 kb, which equals around +10%. That's pretty much for such a simple thing as Base64 encoding. I thought about writing a simple TypeScript implementation of Base64, but then I found a package called abab which provides btoa and atob implementations and increases the bundle size only by 605 bytes. Nevertheless the best would be if there's a way to define certain globals during the build process. There probably is one, but I'm not really into webpack.