css-loader/cjs.js: e.charCodeAt is not a function

[cisox]

next: 11.1.2 node: v14.18.0 (also happens on v14.15.5) next-plugin-preval: 1.2.1

When setting up preval in our project, we ran into this intermittent error on next build:

info  - Creating an optimized production build  
Failed to compile.

./styles/blocks.css.webpack[javascript/auto]!=!./node_modules/next/dist/compiled/css-loader/cjs.js??ruleSet[1].rules[3].oneOf[6].use[1]!./node_modules/next/dist/compiled/postcss-loader/cjs.js??ruleSet[1].rules[3].oneOf[6].use[2]!./styles/blocks.css
TypeError: ./node_modules/next/dist/compiled/css-loader/cjs.js: e.charCodeAt is not a function

The css file differs but it's always the same error when it occurs. It seems to occur about 90% of the time.

This is occurring when building locally as well as in an isolated Docker environment.

Related: https://github.com/vercel/next.js/issues/29301

[thomaskvael]

I also have this problem. It seems to happen kinda randomly. Sometimes i get it during next dev but refreshing the page solves the issue.

The biggest problem is when this error occures during builds. I'm using netlify and every subsequent build will fail. I have to trigger a new build and clear cache to make the build go trough.

After a while the error occurs again.

I can't share the repo since it is client work, but I will try to make some sort of reproduction repo.

I use preval to cache json returned from multiple Apollo requests.

[ricokahler]

hi @cisox and @thomaskvael 👋

i'm having a bit of trouble reproducing this locally. can you provide more details or a clonable reproduction? i'll see what i can do asap.

cc @hborrelli1 in case you want to share thoughts (however feel free to unsubscribe if too much noise)

[cisox]

@ricokahler It turns out that I really only needed to preval one api call and I replaced preval with val-loader instead to avoid this issue.

I also can't share my repo as it's a private repo for work. Ultimately, we had a handful of pages driven by a Strapi backend. They're all pretty much using getStaticProps to pull in data for each individual page but we also had a getInitialProps in _app.js to pull in some global sitewide data such as layout info, etc.

I was using preval to remove getInitialProps and was using preval on pretty much every page including in _app.js. Not sure if that causes any issues but that's probably as far as I can go with reproducing it without setting up a small repo which may or may not even have that issue.

[opexchanger]

Hi, I don't want to add much noise to the thread but I am facing the same issue and it was tough till I narrowed it down to next-plugin-preval. That's a shame cause the plugin is really useful, I have another project with next 10.2.3 and so far it still working fine, so perhaps the error is with next 11 only? I also do not have a public repo to reproduce the behavior, but it was very straightforward, I created a new next project and was adding dependencies by parts to see which one was causing the issue, when I add preval it happens. For my case the configs are default, and I had 3 preval files loading data from sanity cms. Once I remove the preval HOC from my next.config.js, the error stops.

As far as I looked into it, it seems that css-loader is having conflicts with it. If I am not mistaken, next before v11 used webpack 4 if there was custom next config, and css-loader says in its npm page that "To use css-loader, webpack@5 is required", so perhaps it was not present in the version that works? Let me know if I can inform anything else

[thomaskvael]

Hi. I also thought the issue was related to webpack 5 or a newer Next.js version, but I get the same error when I downgrade Next.js and use webpack 4.

I have tried to reproduce this in a repro-repo, but I have not managed to trigger the error yet. I will update this post with a link to a reproduction repo as soon as I have managed to reproduce the error.

[ricokahler]

@thomaskvael and @opexchanger if you can get a reproduction working (in any repository, can be completely fresh), i'll look into a fix right away. thanks for looking into this!

[fabien]

I'm having the same issue, but it appears to be happening every single time during development (although a browser refresh fixes it). I have yet to encounter this during a production build, but according to the comments above that might also happen eventually.

In my case, I am also using next-transpile-modules as well as some aliases in tsconfig.json.

Not sure if that is related in any way, but it started when I added some more aliases and use those inside of some pages (effectively importing some predefined pages into my app, from a module in node_modules). I'm using some aliases in my preval files, too.

Still on NextJS v.10 by the way, and Tailwind in JIT mode. It's hard to share a repo to reproduce it, unfortunately.

[fabien]

So I gave it another shot today, and disabled the Tailwind imports. At first that appeared to help, as I was consistently getting a correct startup of the app, without any issues. However, in another app, the issue returned.

As I mentioned, I haven't had a build fail at all. What I seem to have noticed though, is that during development, my browser is trying to reload the tab as soon as the Next app starts. Doing so appears to trigger the compilation of the css prematurely, in turn causing the error to appear. In other words, from my findings I did not see this issue when there's no browser tab trying to load the page instantly.

Also - and this is another faint guess - it appears that deleting the .next folder before starting the app also helped to prevent it. As if there's some left-over stuff conflicting with the new build - or even some cached scripts in the browser during an attempt to perform a fast-refresh.

Again, only suspicions, nothing definite yet. Don't even know how it all started in the first place either, as it used to work fine for my apps a few months ago.

[fabien]

Quick update: I finally updated my apps to Next 12. I keep seeing this issue, with all relevant dependencies updated.

[thomaskvael]

I have tried to reproduce this without success. But I can confirm what @fabien says. If I delete the .next folder before building, it works.

When I have some more spare time, I will try to debug this further.

[akshitkrnagpal]

Hey All

I was trying to figure this out. Just wanted to add my findings.

This error seems to be open issue in babel. https://github.com/babel/babel/issues/13815 From the conversation, this was a bug in @babel/plugin-proposal-unicode-property-regex which was fixed in https://github.com/babel/babel/pull/13767 and is released in babel version 7.15.7. Link of release - https://github.com/babel/babel/releases/tag/v7.15.7

I am seeing older babel version pinned in nextjs but not sure if that is the cause. (Babel Newbie here 😄 ) https://github.com/search?q=babel+repo%3Avercel%2Fnext.js+filename%3Apackage.json+path%3A%2Fpackages&type=Code&ref=advsearch&l=&l=

Hope this helps someone figure this out.

[fabien]

Just another quick update. Now that I am on Next 12, I have encountered this issue for the first time during production builds - it happens during every single build attempt. So unless we can fix this somehow, I will not be able to deploy any apps :-(

@thomaskvael deleting .next doesn't seem to help in this case either.

@akshitkrnagpal thanks for investigating. As I only updated to Next 12, I'm not sure here, but isn't the new SWC based compiler meant to replace babel? As I don't have a .babelrc in my projects, I was presuming it was already using SWC, which would imply that it should sidestep the issue you outlined above.

Update/wild guess: perhaps the NodeJS target should be incremented here?

https://github.com/ricokahler/next-plugin-preval/blob/a29efcab510f92a46e7df4e4f7ba2c5cd5ea1e3e/src/loader.ts#L79

[ricokahler]

@akshitkrnagpal, if it is an issue with a babel dependency, could you try forcing the resolution to the latest/fixed version of babel? You can do this by using yarn resolutions or npm-force-resolutions. After you add the forced resolution config and reinstall, you should be able to check to see if it worked by looking at your respective lockfile. You shouldn't be able to find any other version.

If this works I can re-working next-plugin-preval's babel config with specified versions as dependencies to fix it without needing to specify resolutions.

@fabien I definitely can bump that target if it helps. It probably should be bumped anyway. The minimum Node.js required for Next.js 12 is 12.22.0 now.

---

I'm also willing to hop on a call and figure this out synchronously if anyone has the time. Feel free to email me or DM me on Twitter and we can figure out a time.

[github-actions[bot]]

:tada: This issue has been resolved in version 1.2.3 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket:

[akshitkrnagpal]

but isn't the new SWC based compiler meant to replace babel?

@fabien I am not a nextjs expert but I think the babel plugins needs to be individually migrated from babel compiler. There are a few issues in nextjs repo. See here - https://github.com/vercel/next.js/issues?q=is%3Aissue+is%3Aopen+label%3A%22area%3A+SWC+transforms%22

if it is an issue with a babel dependency, could you try forcing the resolution to the latest/fixed version of babel? You can do this by using yarn resolutions or npm-force-resolutions. After you add the forced resolution config and reinstall, you should be able to check to see if it worked by looking at your respective lockfile. You shouldn't be able to find any other version.

@ricokahler I think nextjs doesn't use it babel like that. I think they have some precompiled js. And in my stack trace, this is the file that throws error. I think we'll have to fork nextjs to update this file? Not sure. https://github.com/vercel/next.js/blob/canary/packages/next/compiled/babel-packages/packages-bundle.js

[ricokahler]

@akshitkrnagpal ah that makes a lot of sense. next.js 12 mightve significantly changed how this works though i'm curious why the example app in the CI isn't breaking.

im using babel + babel register right now to compile the code for execution in node.js. after the code is executed, the result is serialized and passed to webpack as a json string. it might help to completely skip the next babel preset and use babel independently (or even a similar even register hook). i'll play around with that today.

[devon2018]

Is there any update on this issue, using nextjs v11 it was failing randomly but since upgrading to 12 its failing every time when deploying, but for some reason not when i build locally.

[ricokahler]

@devon2018 can you provide more details on when/where it fails and where you're deploying to?

[benjaminleonard]

I still have the error on both Next 11 and Next 12. Anecdotally it seems much more likely to fail when I deploy to Vercel than when I build locally.

[akshitkrnagpal]

@ricokahler One local. I was able to reproduce if I do yarn install and then checkout another branch. then do next build. Then it starts working if we switch back to another branch.

On Vercel, Error happens when vercel cache is there. it always work fine if I redeploy without cache.

[ricokahler]

Alright, i think i finally got this one. After lots of stack trace following and a helpful call with @fabien, I think this one is solved.

The solution was relatively simple as well. See #77 and v1.2.4

Thanks for hanging in there everyone!