@spirulence is attempting to deploy a commit to the Codemod Team on Vercel.

A member of the Team first needs to authorize it.

Open in Stackblitz

npm i https://pkg.pr.new/codemod@1483

commit: 47d480e

The latest updates on your projects. Learn more about Vercel for Git ↗︎

@spirulence I'm unable to build turbo build --filter codemod unless I handle .node files in the build configuration in apps/cli/build.js:

build({
  ..
  ...
  platform: "node",
  target: "node18",
  loader: {
    ".node": "file", // Configure esbuild to handle ".node" files as file assets
  },
  ...

Are you able to reproduce this?

@spirulence I'm unable to build turbo build --filter codemod unless I handle .node files in the build configuration in apps/cli/build.js:

build({
  ..
  ...
  platform: "node",
  target: "node18",
  loader: {
    ".node": "file", // Configure esbuild to handle ".node" files as file assets
  },
  ...

Are you able to reproduce this?

I was not. Let me check.

@mohab-sameh Unfortunately I am not able to replicate this, either in the Ubuntu 24 environment I use in normal development or on my MacBook. Turbo build commands run to success on both.

I may still be able to help identify the issue. Can you share more details about what platform you're developing on, including Node version, npm version, pnpm version, Turbo version, operating system, processor architecture, and the error you receive when you do not include the file loader for .node executables in the esbuild configuration?

The two platforms I double-checked:

Node v20.18.3 
NPM 10.8.2
PNPM 9.5.0
Turbo 1.13.4
Ubuntu 24.04 (DigitalOcean default image)
x64

Node v20.18.3 
NPM 10.8.2
PNPM 9.5.0
Turbo 1.13.4
macOS Sonoma 14.6.1
M1 Pro

Please forgive any of the following details that you already know. I include a lot of context so that our discussion on this issue may be a helpful artifact to your team in the future for any similar issues involving packaged binaries and local build processes.

There are at least a couple of ways we can resolve this.

1) Change build configuration

The first would be to figure out if your fix for the turbo build command is something that should be added to esbuild configuration permanently. It is also possible that there is some other equal change that would suffice.

The filetype you've had to handle specifically is usually from an artifact being packaged as a native executable, either in an external dependency or one from inside the workspace. The error you receive may be able to help identify which .node file is not able to be found.

In my experience, the presence of these native binaries can be platform dependent. Projects may change the type of their packaged artifact per platform, especially if they attempt to target Windows in addition to Alpine (musl) and Debian/RHEL linux (libc), not to mention different ways of supporting arm and x86 architectures.

If the error message you receive is insufficient to find the specific dependency or dependencies causing the issues, it may be helpful to use a find command like so, if available on your platform, to find which native executables may be needed for your local esbuild process. Here's what I receive running from the root of the repo (on Ubuntu 24), and it's not actually that many.

find . -name "*.node" 
./node_modules/.pnpm/@ast-grep+napi-linux-x64-gnu@0.25.4/node_modules/@ast-grep/napi-linux-x64-gnu/ast-grep-napi.linux-x64-gnu.node
./node_modules/.pnpm/@rollup+rollup-linux-x64-musl@4.34.4/node_modules/@rollup/rollup-linux-x64-musl/rollup.linux-x64-musl.node
./node_modules/.pnpm/@rollup+rollup-linux-x64-gnu@4.34.4/node_modules/@rollup/rollup-linux-x64-gnu/rollup.linux-x64-gnu.node
./node_modules/.pnpm/@next+swc-linux-x64-gnu@14.2.4/node_modules/@next/swc-linux-x64-gnu/next-swc.linux-x64-gnu.node
./node_modules/.pnpm/@next+swc-linux-x64-musl@14.2.4/node_modules/@next/swc-linux-x64-musl/next-swc.linux-x64-musl.node
./node_modules/.pnpm/@msgpackr-extract+msgpackr-extract-linux-x64@3.0.3/node_modules/@msgpackr-extract/msgpackr-extract-linux-x64/node.napi.musl.node
./node_modules/.pnpm/@msgpackr-extract+msgpackr-extract-linux-x64@3.0.3/node_modules/@msgpackr-extract/msgpackr-extract-linux-x64/node.napi.glibc.node
./node_modules/.pnpm/@msgpackr-extract+msgpackr-extract-linux-x64@3.0.3/node_modules/@msgpackr-extract/msgpackr-extract-linux-x64/node.abi115.musl.node
./node_modules/.pnpm/@msgpackr-extract+msgpackr-extract-linux-x64@3.0.3/node_modules/@msgpackr-extract/msgpackr-extract-linux-x64/node.abi115.glibc.node
./node_modules/.pnpm/@prisma+engines@5.15.1/node_modules/@prisma/engines/libquery_engine-debian-openssl-3.0.x.so.node
./node_modules/.pnpm/keytar@7.9.0/node_modules/keytar/build/Release/keytar.node
./node_modules/.pnpm/@ast-grep+napi-linux-x64-musl@0.25.4/node_modules/@ast-grep/napi-linux-x64-musl/ast-grep-napi.linux-x64-musl.node
./node_modules/.pnpm/prisma@5.15.1/node_modules/prisma/libquery_engine-debian-openssl-3.0.x.so.node

My money is on a .node file, used in vitest coverage, that is missing without the special handling you've added. This would be one area, tracing and profiling, where different platforms have very different approaches to instrumentation. This would be easily differentiated by seeing if pnpm unit succeeds and pnpm coverage does not.

2) Different reproduction script

It is highly likely that the way I'm running these unit tests is not standard.

I did only a rudimentary search of the repo to try and find the standard way that developers are running these unit tests during development and didn't come up with anything. When I attempted to run pnpm coverage or pnpm unit before turbo build I would get errors related to the units under test not being able to find intra-workspace dependencies, even though the source code is available.

So I lifted these commands from the way that they are invoked in CI. See

Please check if pnpm build instead of turbo build works for you. If so, I'll change the reproduction script here. If it's that easy, that would be ⭐ amazing ⭐ .

YOU GUYS ARE THE BEST