Octal escape sequences causing NextJS builds to fail

[andrewAtSandtable]

What happened?

TLDR; I suspect cesium/engine v24.0.0 introduced a bug that's causing NextJS builds fail to compile typescript

I first noticed the issue on cesium v1.140.0 after refactoring my code which caused cesium to upgrade to the latest available version.

Cesium v1.134.0 was the first version I could rollback to where the failure did not occur. I found it by manually rolling back one version at a time until next js build would succeed.

The NextJS Failure

When I run my build script, the typescript step is failing on multiple of these errors:

Error [ChunkLoadError]: Failed to load chunk server/chunks/ssr/_0qxhg3f._.js from module 178555
    at Context.loadChunkAsync [as l] (.next/server/chunks/ssr/[turbopack]_runtime.js:766:27) {
  digest: '3505959538',
  [cause]: SyntaxError: Octal escape sequences are not allowed in template strings.
      at <unknown> (.next/server/chunks/ssr/_0qxhg3f._.js:865)
}

Environment

If it helps to debug, I'm running:

• node v22.16.0
• next v16.2.2
• typescript v5.9.3
• react v18.2.0

cesium/engine v24.0.0

Knowing that cesium v1.134.0 was the last version where my next js build were succeeding, I started to compare the dependencies against cesium v1.135.0

Comparing cesium dependencies after an install

  cesium@1.134.0:
    dependencies:
      '@cesium/engine': 21.0.1
      '@cesium/widgets': 13.2.1

  cesium@1.135.0:
    dependencies:
      '@cesium/engine': 22.3.0
      '@cesium/widgets': 14.5.0

Differences in cesium/widgets installed dependencies

One oddity is that cesium/widgets 14.5.0 installed cesium/engine 24.0.0 which was further along than what cesium 1.135.0 required

 '@cesium/widgets@13.2.1':
    dependencies:
      '@cesium/engine': 21.0.1
      nosleep.js: 0.12.0

  '@cesium/widgets@14.5.0':
    dependencies:
      '@cesium/engine': 24.0.0
      nosleep.js: 0.12.0

Difference in cesium/engine installed dependencies

Below, I'm only showing the dependencies that changed across the cesium/engine version, and because cesium/widgets 14.5.0 installed cesium/engine 24.0.0, we have 3 cesium/engines to compare.

Since the failure only happens once cesium/engine 24.0.0 is involved, and that version remains involved in every next cesium release up to v1.140.0; I suspect one of cesium/engine's dependencies or its internal code contains the issue causing the next js build failures. When you compare to cesium/engine 22.3.0, the only change in dependencies is @spz-loader/core from 0.3.0 to 0.3.1

  '@cesium/engine@21.0.1':
    dependencies:
      '@spz-loader/core': 0.3.0
      meshoptimizer: 0.25.0
      protobufjs: 7.5.4

  '@cesium/engine@22.3.0':
    dependencies:
      '@spz-loader/core': 0.3.0
      meshoptimizer: 1.1.0
      protobufjs: 8.0.1

  '@cesium/engine@24.0.0':
    dependencies:
      '@spz-loader/core': 0.3.1
      meshoptimizer: 1.1.0
      protobufjs: 8.0.1

Reproduction steps

Might be difficult but...

1. Create a next js app
2. Add cesium v1.140.0 as a dependency
3. npm run build
4. See the build fail

Sandcastle example

No response

Environment

Browser: Chrome version 146.0.7680.178 (Official Build) (arm64)
CesiumJS Version: 1.140.0
Operating System: macOS Sequoia 15.7.4

AI acknowledgment

• I used AI to generate this issue report.
• (If the above is checked) I have reviewed the AI-generated content before submitting.

[jjspace]

Sorry you're running into issues @andrewAtSandtable. It would be really helpful if you could provide the actual lines or at least the file that the error is originating in. Seeing an SSR chunk does not provide much info. AFAICT from a quick search I don't see any template strings that violate this rule in CesiumJS but it's possible I missed something.

[andrewAtSandtable]

Hi @jjspace and thanks for the quick reply.

I think I narrowed down the chunk to:

node_modules/.pnpm/@cesium+engine@24.0.0/node_modules/@cesium/engine/Source/ThirdParty/draco_decoder.wasm

[marcoYxz]

I am experiencing the same problem on Cesium v1.140.0. It was working on Cesium v1.139.0. The error happens when we build our front end and set optimization strategy, minimize to true

I've narrowed it down to node_modules/@spz-loader/core/dist/index.js

Steps:

1. Build our frontend and visit it, we are seeing

2. Enable source map and run this snippet

node -e '
const fs = require("fs");
const { SourceMapConsumer } = require("source-map");

const raw = JSON.parse(fs.readFileSync("app.da92e4feb772f513.js.map", "utf8"));

new SourceMapConsumer(raw).then
  ? new SourceMapConsumer(raw).then(consumer => {
      const pos = consumer.originalPositionFor({ line: 3077, column: 764 });
      console.log(pos);
      consumer.destroy && consumer.destroy();
    })
  : (() => {
      const consumer = new SourceMapConsumer(raw);
      const pos = consumer.originalPositionFor({ line: 3077, column: 764 });
      console.log(pos);
      consumer.destroy && consumer.destroy();
    })();
'

Result:

{
  source: '/node_modules/@spz-loader/core/dist/index.js',
  line: 1383,
  column: 0,
  name: null
}

[javagl]

One change in that area was the update of the SPZ loader library that went into 1.140, via #13329

I have no clue what the context or error message is here.
But when you change the line in the dependencies of the package.json from
"@spz-loader/core": "0.3.1" to
"@spz-loader/core": "0.3.0"
and try again, and it then works, we have at least narrowed it down a bit. (Hoping that there are no breaking changes between these versions)

[WillGrayMSU]

I can confirm the same error when we bundle our app using RS Build. I can also confirm that the problem is due to @spz-loader/core: 0.3.1. We have applied an override to @spz-loader/core: 0.3.0 for now.

[andrewAtSandtable]

Comparing @spz-loader/core 0.3.0 vs 0.3.1: drumath2237/spz-loader@v0.3.0...v0.3.1

[andrewAtSandtable]

Linking: drumath2237/spz-loader#89

[javagl]

When I see things like
at <unknown> (.next/server/chunks/ssr/_0qxhg3f._.js:865)
in error messages ... *sigh* ... why? I mean, seriously, why?

Looking at the comparison that was linked above, I see a bunch of random changes in build files, and a tiny, innocent change in one of the actual source files. Can someone provide a "one-sentence summary for dummies (like me)" explaining what that 'Octal escape sequence' is, where it comes from, what it means, and how it can be avoided?

[jjspace]

Can someone provide a "one-sentence summary for dummies (like me)" explaining what that 'Octal escape sequence' is

@javagl This was helpful to me: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Deprecated_octal_escape_sequence

That said, even looking at that the change in spz-loader doesn't seem to introduce an issue here unless it's something inside the wasm itself so it's really weird