compile error

[aipinsui]

What happened?

when i excute npm run build-apps,compile error appear,please repair this question

PS G:\cesium> npm run build-apps

cesium@1.135.0 build-apps
gulp -f gulpfile.apps.js buildApps

[22:28:12] Using gulpfile G:\cesium\gulpfile.apps.js
[22:28:12] Starting 'buildApps'...
[22:28:12] Starting 'buildCesiumViewer'...
[22:28:12] Starting 'buildLegacySandcastle'...
[22:28:12] Starting 'buildSandcastle'...
[22:28:13] 'buildSandcastle' errored after 819 ms
[22:28:13] TypeError: Invalid URL
at new URL (node:internal/url:825:25)
at fileURLToPath (node:internal/url:1605:12)
at typescriptCompile (file:///G:/cesium/packages/sandcastle/scripts/typescriptCompile.js:13:19)
at buildStatic (file:///G:/cesium/packages/sandcastle/scripts/buildStatic.js:136:26)
at buildSandcastleApp (file:///G:/cesium/scripts/buildSandcastle.js:135:9)
[22:28:13] 'buildApps' errored after 821 ms

Reproduction steps

1.npm run build-apps
2.
3.
...

Sandcastle example

No response

Environment

Browser:chrome 142.0.7444.60
CesiumJS Version:1.135
Operating System:windows11

[javagl]

(@jjspace This is in the same area as the build issues that I mentioned in #13013 (review) , but a diffrent flavor of that - maybe some of the differences are related to the Node version or OS...?)

@aipinsui

You could try to replace the file https://github.com/CesiumGS/cesium/blob/edceb42f3ac54aa3e3ebef17ab96f3d2f39f133c/packages/sandcastle/scripts/typescriptCompile.js with this one

import { spawn } from "node:child_process";
import { join } from "node:path";
import { fileURLToPath } from "node:url";

/**
 * Compile a typescript project from it's config file using the tsc CLI
 *
 * @param {string} configPath Absolute path to the config file to build
 * @returns {number} exit code from the tsc command
 */
export default async function typescriptCompile(configPath) {
  const tsPath = import.meta.resolve("typescript");
  console.log("tsPath", tsPath);
  const fullPath = join(tsPath, "../../bin/tsc")
  console.log("fullPath", fullPath);
  const binPath = fileURLToPath(fullPath);
  console.log("binPath", binPath);
  return new Promise((resolve, reject) => {
    const ls = spawn(binPath, ["-p", configPath]);

    ls.stdout.on("data", (data) => {
      console.log(`stdout: ${data}`);
    });

    ls.stderr.on("data", (data) => {
      console.error(`stderr: ${data}`);
    });

    ls.on("close", (code) => {
      if (code === 0) {
        resolve(code);
      } else {
        reject(code);
      }
    });
  });
}

and run the command again.

It will then print some log messages like

tsPath file:///C:/cesium/node_modules/typescript/lib/typescript.js
fullPath file:\C:\cesium\node_modules\typescript\bin\tsc
binPath C:\cesium\node_modules\typescript\bin\tsc

that may help to figure out what exactly is going on there.

(For me, this leads to the "Error: spawn C:\cesium\node_modules\typescript\bin\tsc ENOENT" error, but whether or not that's related remains to be figured out...)

[Leafmire]

For "Error: spawn C:\cesium\node_modules\typescript\bin\tsc ENOENT" case
In my case, add node exec command in spawn function fixes mine.

typescriptCompile.js

import { spawn } from "node:child_process";
import { join } from "node:path";
import { fileURLToPath } from "node:url";

/**
 * Compile a typescript project from it's config file using the tsc CLI
 *
 * @param {string} configPath Absolute path to the config file to build
 * @returns {number} exit code from the tsc command
 */
export default async function typescriptCompile(configPath) {
  const tsPath = import.meta.resolve("typescript");
  const binPath = fileURLToPath(join(tsPath, "../../bin/tsc"));
  return new Promise((resolve, reject) => {
    // this line changed
    const ls = spawn(process.execPath, [binPath, "-p", configPath]);

    ls.stdout.on("data", (data) => {
      console.log(`stdout: ${data}`);
    });

    ls.stderr.on("data", (data) => {
      console.error(`stderr: ${data}`);
    });

    ls.on("close", (code) => {
      if (code === 0) {
        resolve(code);
      } else {
        reject(code);
      }
    });
  });
}

[javagl]

In my case, add node exec command in spawn function fixes mine.

That's interesting. I didn't dive into my error (just "worked around" it, in a way that I won't post here 😉 ). I also tried prefixing the path with node or npx, and that didn't work. But I wasn't aware of that execPath. Maybe that's a clean way to resolve this...?

[wewindy]

I also catch this problem.

Environment

• Windows 11
• NodeJS 22.21
• CesiumJS Latest

So I add some logs too:

const tsPath = import.meta.resolve("typescript");
console.log(tsPath);
console.log(join(tsPath, "../../bin/tsc"));

And I got:

file:///D:/openworks/cesium/node_modules/typescript/lib/typescript.js # <- it is a file url
.\file:\D:\openworks\cesium\node_modules\typescript\bin\tsc

Notice that the return value of import.meta.resolve() is a file url, then join(tsPath, "../../bin/tsc") return a strange path. For file url, I use fileURLToPath to dealing it:

import { spawn } from "node:child_process";
import { resolve } from "node:path";
import { execPath } from "node:process";
import { fileURLToPath } from "node:url";

export default async function typescriptCompile(configPath) {
  const tsPath = import.meta.resolve("typescript");
  const binPath = resolve(fileURLToPath(tsPath), "../../bin/tsc") // convert tsPath to path first, resolve secondary
  return new Promise((resolve, reject) => {
    const ls = spawn(execPath, [binPath, "-p", configPath]); // <- 👀 use execPath to execute tsc
    // ...
  })
}

Then works well:

But after build-sandcastle, I run start-public, sandcastle2 page has no gallery :( ...

[javagl]

@wewindy

But after build-sandcastle, I run start-public, sandcastle2 page has no gallery :( ...

That might be #12951 . If it is, then there is a draft for "fixing" this in #12988 , but the exact way how this will be solved still has to be decided. (That mix of paths and URLs on different OSes *head spins*...)

[jjspace]

Sorry for the issues here. I find myself once again increasingly frustrated at the annoying (bad) way Windows handles paths and the difference in behavior from Node itself to "account" for that. I don't have easy access to test the changes on Windows so it's felt like a game of whack-a-mole trying to track them all down.

I'm looking into changes here and the linked issues @javagl was seeing to try and address them all the "right way" (🤞) with testing help from him and others.

[Beilinson]

For me replacing with npx tsc -p ${configPath} fixed the issue. Why manually resolve the tsc bin when npx exists?

I think this entire function could be replaced with:

export default function typescriptCompile(configPath) {
  return execSync(`npx tsc -p ${configPath}`;
}

[jjspace]

Why manually resolve the tsc bin when npx exists?

Stability and consistency of where we're pulling typescript from. We also need to use this in the build code for the ion-sdk which does not have typescript as a direct dependency. npx, as I understand it, will use whatever version is in the node modules. This could either not exist (in our case) or be a different version of typescript than the one we expect (possible in this repo if the root and sandcastle packages differ, unlikely though).
I originally tried using the compiler API directly but it's not documented very well and not officially stable so we switched back to trying to use the tsc CLI.