can not run `npm ci`

[Sysix]

When running npm ci, the command will fail because oxc_language_server.exe inside node_modules is in use.
I need to disable the oxc intellij plugin before running this command.

Sadly, I can not provide you with a better error description, because this was on the company machine.
My private machine does not have an IntelliJ product.

[nrayburn-tech]

The problem is the language server is still running when you attempt to run npm ci, which deletes the node_modules folder. Because the language server is running, it can’t be deleted, and the command fails.

I’ll look into what I can change for this. Even when you close all relevant files, the language server keeps running currently.

[nrayburn-tech]

This is a Windows only problem due to how linux/macOS removes files compared to Windows. I made some updates that should resolve it and will be part of 0.0.13. I don't know that I'll actually be able to test it on Windows until Monday at the earliest though.

[nrayburn-tech]

And to be clear, you'll still need to close all relevant files (.js, .ts, etc.) before running npm ci. If you have any files open that trigger the language server to run, then you'll still encounter issues.

If you have suggestions on how to further improve this, let me know. I'm not sure of anything else that can be done though. I would expect other language servers to have a similar problem, but I didn't test to confirm.

[Sysix]

@nrayburn-tech I tested it today with my team. Somehow we still got a running oxc_language_server.exe after "Closing All Tabs".
Needed to manually kill it with the task manager. Using PHP Storm 2025.1.3.
Please tell me if (and how) you need information.

[nrayburn-tech]

I’ve seen a separate approach to this. I’m not super fond of it, but it would work.

Instead of running the exe from node_modules, the plugin could copy it to a temp directory and run it from there. Then, you could do npm ci as expected. The risk is that the plugin would need to always detect when this happens, otherwise the wrong exe could be running.

[nrayburn-tech]

I haven't had a chance to implement a fix for this yet, but I think the approach of running the files from a temp directory is something like the below.

1. Create a new configuration option that is only available when the automatic config option is selected and the user's OS is Windows, something like "temp cache directory". When this is configured, it will enable the below behavior.
2. Watch oxlint/** and @oxlint/** directories for changes. Anytime a change happens, sync it to the temp cache directory.
3. The plugin executes using the files in the temp cache directory instead of the standard node_modules directory.
4. If the plugin attempts to execute and the file isn't available in the temp cache directory, it attempts to copy it from the standard node_modules directory (shouldn't really be necessary, sort of an edge case if file watching doesn't work for some reason).

[nrayburn-tech]

Besides the temp cache directory approach, I still don't understand why the language server would still be running after closing all of the editor tabs. There's not really anything complex about that code. I don't think there's any logging in that area to help troubleshoot though.

[Sysix]

I think the temp directory is a good start. If would not include a watcher.
Just at the start of the plugin copy the nearest language server in the temporary directory.
That how nx solved it: nrwl/nx-console/issues/2026

https://github.com/nrwl/nx/blob/ccff88e27a7ec3801530bbbc4721a31287a0b735/packages/nx/src/native/index.js#L43-L69

[nrayburn-tech]

Thanks for the reference links. I’ll get something out this weekend that should cover the common cases.

[nrayburn-tech]

Reviewing this some more. I think for me to implement this in the IntelliJ plugin, I would have to build out and maintain the map of native executables to platform/arch.

I also don't understand why the VS Code plugin doesn't have the same problem (or maybe it does and hasn't been reported?).

What do you think about implementing this in the oxc_language_server js script in a similar way that nx did?

[Sysix]

I also don't understand why the VS Code plugin doesn't have the same problem (or maybe it does and hasn't been reported?).

Because the .exe is in the Plugin directory. Only when someone defines oxc.path.server, a node_modules could be targeted.

I think for me to implement this in the IntelliJ plugin, I would have to build out and maintain the map of native executables to platform/arch.

What do you think about implementing this in the oxc_language_server js script in a similar way that nx did?

./node_modules/oxlint/.bin/oxc_language_server has a mapping for it.
But still the .exe files needs to be copied, not the js file referencing the .exe file

const isMusl = () => {
  let musl = false;
  if (process.platform === "linux") {
    musl = isMuslFromFilesystem();
    if (musl === null) {
      musl = isMuslFromReport();
    }
    if (musl === null) {
      musl = isMuslFromChildProcess();
    }
  }
  return musl;
};

const isFileMusl = (f) => f.includes("libc.musl-") || f.includes("ld-musl-");

const isMuslFromFilesystem = () => {
  const { readFileSync } = require("fs");
  try {
    return readFileSync("/usr/bin/ldd", "utf-8").includes("musl");
  } catch {
    return null;
  }
};

const isMuslFromReport = () => {
  const report =
    typeof process.report.getReport === "function"
      ? process.report.getReport()
      : null;
  if (!report) {
    return null;
  }
  if (report.header && report.header.glibcVersionRuntime) {
    return false;
  }
  if (Array.isArray(report.sharedObjects)) {
    if (report.sharedObjects.some(isFileMusl)) {
      return true;
    }
  }
  return false;
};

const isMuslFromChildProcess = () => {
  try {
    return require("child_process")
      .execSync("ldd --version", { encoding: "utf8" })
      .includes("musl");
  } catch (e) {
    // If we reach this case, we don't know if the system is musl or not, so is better to just fallback to false
    return false;
  }
};

const { platform, arch, env, version, release } = process;

const BIN_NAME = "oxc_language_server";

const PLATFORMS = {
  win32: {
    x64: {
      musl: `@oxlint/win32-x64/${BIN_NAME}.exe`,
      gnu: `@oxlint/win32-x64/${BIN_NAME}.exe`,
    },
    arm64: {
      musl: `@oxlint/win32-arm64/${BIN_NAME}.exe`,
      gnu: `@oxlint/win32-arm64/${BIN_NAME}.exe`,
    },
  },
  darwin: {
    x64: {
      musl: `@oxlint/darwin-x64/${BIN_NAME}`,
      gnu: `@oxlint/darwin-x64/${BIN_NAME}`,
    },
    arm64: {
      musl: `@oxlint/darwin-arm64/${BIN_NAME}`,
      gnu: `@oxlint/darwin-arm64/${BIN_NAME}`,
    },
  },
  linux: {
    x64: {
      musl: `@oxlint/linux-x64-musl/${BIN_NAME}`,
      gnu: `@oxlint/linux-x64-gnu/${BIN_NAME}`,
    },
    arm64: {
      musl: `@oxlint/linux-arm64-musl/${BIN_NAME}`,
      gnu: `@oxlint/linux-arm64-gnu/${BIN_NAME}`,
    },
  },
};

let binPath = PLATFORMS[platform]?.[arch]?.[isMusl() ? "musl" : "gnu"];

Full code can be seen at https://www.npmjs.com/package/oxlint?activeTab=code

[nrayburn-tech]

For the first point, I still disagree with shipping the exe as part of the plugin but maybe that’s what the IntelliJ plugin should do as well to avoid this issue and be more similar to the VS Code plugin.
This doesn’t eliminate the issue, but it reduces how often it might come up.

For the second one, yes the exe needs to be copied. I would have to define that mapping logic so that I know where to look on the file system to copy the exe file. I’m not sure how this works with the new type aware exe either, so that could be another problem to solve.