-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
SSR Error After Upgrading from 8.8 to 8.9 #7735
Comments
+1 |
Tried a few tricks to see if I could get this to work on Next v13.x.x but unfortunately none of them worked:
|
In 8.9 a few upstream dependencies are updated to their latest version, including You may want to look into next.js config that lets you control the module resolution for server-side bundle - Whatever the solution is, we cannot go backward on these dependencies. Security vulnerabilities in those libraries are not fixed in the old versions. Edit: I spent a little time poking around and it doesn't seem easy to override next's webpack configs. At this point I would recommend isolating your deck.gl-related imports and exclude it from SSR: /// components/deck-map.js
import DeckGL, {TextLayer} from 'deck.gl';
export default function DeckMap() {
return <DeckGL ... />
}
/// pages/index.js
import dynamic from 'next/dynamic';
const DeckMap = dynamic(() => import('../components/deck-map'), {
ssr: false
});
export default function Home() {
return <DeckMap />;
} deck.gl renders into a WebGLContext so it wouldn't benefit from SSR anyways. |
This fixes the tests that were failing. It looks like @deck.gl uses dependencies that were converted to esm modules and jest isn't currently set up to handle them. ``` Jest encountered an unexpected token ... /home/runner/work/react-map-gl/react-map-gl/node_modules/@deck.gl/layers/node_modules/@mapbox/tiny-sdf/index.js:3 export default class TinySDF { ^^^^^^ SyntaxError: Unexpected token 'export' ``` Reference: visgl/deck.gl#7735
@Pessimistress: I'm loading DeckGL (v8.9.2) and NebulaGL with a dynamic import (ssr: false), but I still get this issue when I build |
@DonovanCharpin The problem is not the DeckGL component. You cannot import any layer that reference the above mentioned modules (e.g. |
@Pessimistress my component contains a map and is loaded dynamically (not ssr) const MyMap = dynamic(
() => import("../../components/react-map-gl/static-react-map-gl.component"),
{
ssr: false,
}
); This component imports |
@DonovanCharpin Look at the trace stack of the error and it will tell you which component is doing the problematic import. Sorry I can't be of more assistance because I can only speculate based on your description. |
@Pessimistress The stack was mainly the same as the one shared above. I will post my stack here as well if it can help. But basically, I don't use deckGL outside of this component and this component is not loaded on SSR, so I'm not sure what would be wrong. |
I was able to confirm the fix proposed by @Pessimistress worked for us. We have a similar sounding setup @DonovanCharpin
|
I ran into this with vitest as well due to vitest-dev/vitest#2834. Adding |
You're awesome! This has solved my deployment issue! <3 |
I've tried,seems to be working. |
None of the above works for me ! |
@fromwhite can you share your component and config setup? |
It doesn't work for me |
I have disabled SSR now. |
This is quite niche but I also encountered this issue using rakkas framework. I've tried to do what's described here but nothing helped, until I moved the piece of code that was using |
@x17Andrew71x this weird because i tried it before and it didn't work |
That's great that you got it, my guess would be there's a version difference somewhere in the installed packages. |
Hello, I have created a repo to reproduce the problem and how to fix this thanks to @Pessimistress There are 2 pages: index and working The index page throws the error described in this issue: Error: require() of ES Module /project/deckgl-error/node_modules/@mapbox/tiny-sdf/index.js from /project/deckgl-error/node_modules/@deck.gl/layers/dist/es5/text-layer/font-atlas-manager.js not supported. The page working is refactored in order to move the deckgl code to a component and dynamically import that component with ssr:false I hope there is a better way to do this. We have a big app and the refactoring will take some time. PS: If you want to see the map, you have to enter your mapbox token in the MAPBOX_ACCESS_TOKEN variable Github: codeSandbox: code |
Hey guys, I still have the issue with the latest version. I'm importing the map dynamically (ssr:false) and I'm using these imports in the map component: import DeckGL from "@deck.gl/react";
import { BitmapLayer, IconLayer, TextLayer } from "@deck.gl/layers"; Could this be linked? Here is the stack I get when I run a require() of ES Module /xxx/node_modules/.pnpm/@mapbox+tiny-sdf@2.0.5/node_modules/@mapbox/tiny-sdf/index.js from /xxx/node_modules/.pnpm/@deck.gl+layers@8.9.9_@deck.gl+core@8.9.9/node_modules/@deck.gl/layers/dist/es5/text-layer/font-atlas-manager.js not supported.
Instead change the require of index.js in /xxx/node_modules/.pnpm/@deck.gl+layers@8.9.9_@deck.gl+core@8.9.9/node_modules/@deck.gl/layers/dist/es5/text-layer/font-atlas-manager.js to a dynamic import() which is available in all CommonJS modules. |
@DonovanCharpin Be sure you are dynamically importing everywhere in your code. Probably theres is a "component" that is importing deckgl packages without the ssr |
@xap5xap I found the issue... You are right, there was a constant export.
that was used in another part of the code and created the issue shared previously! This is a good catch because I will check all my dynamic imports now! |
Seems it might still be an issue with aggregation layers. The above fix works but as soon as I try and use the HexagonLayer |
For people with a vitest issue about an ESM import, if alias failed then you can try this in your beforeAll(() => {
vitest.mock('@deck.gl/layers/typed', () => {
return {
default: () => {},
GeoJsonLayer: class GeoJsonLayer{},
PathLayer: class PathLayer{},
TextLayer: class TextLayer{},
// ... whatever layers you are using
}
})
}) Hope it helps :) |
For a NextJS setup, adding See https://nextjs.org/docs/app/building-your-application/rendering/client-components |
I still have the issue, and as @theonlydaleking said, there might be an issue with aggregation layers. Here is my stack with next
My files are all imported dynamically with dynamic, and I even tested "use client"; with no luck. I did not upgrade deck.gl to Also, the stack above specifies deck gl I tried also the other solutions above with transpile etc. UPDATENevermind, I had to install @deck.gl/layers, it was working with just deck.gl before. |
I struggled with this issue for a quite a while with none of the solutions here working for me. Eventually I stumbled into this section of the docs for anyone also having issues.
|
this does not work for me |
A possible solution here would be to configure our build step to bundle The main obstacle is that the esbuild API does not offer a good way to specify, "externalize everything except X". Without that we'd have to explicitly list every dependency that isn't X. I've upvoted the relevant feature requests on esbuild...
... and offered to contribute a CommonJS build to Either of those should unblock deckgl. |
deck.gl v9.0 is now a fully compliant ES Module. |
If this issue is still affecting anyone in v9.0, please let us know. There's a possible workaround proposed in uber-web/ocular#460, but I don't expect we'll move forward without (1) confirming the problem still exists in v9, and (2) understanding which runtime environments the issue still affects. Thanks! |
Description
After upgrading from 8.8 to 8.9 via
npm update
, I receive the following error when trying to build my NextJS App:Flavors
Expected Behavior
After reading the Upgrade Guide, I didn't notice any breaking changes that should affect my code as it is. I should still be able to build my app.
Steps to Reproduce
I will try and supply this, but judging from the stack trace I supplied something seems to be amiss
Environment
Logs
No response
The text was updated successfully, but these errors were encountered: