fix(cli): update vitest, fix coverage command and unmet peer

[spirulence]

📚 Description

Coverage report generation for the cli is failing with a TypeError. Fix is to update the vitest version to match the coverage provider version installed in the catalog.

In addition, fixes an unmet peer warning in the cli application due to the coverage provider package wanting the updated version of vitest installed.

🔗 Linked Issue

• Fixes #1482

🧪 Test Plan

Use the following reproduction script:

#!/bin/bash
set -e

# can be ommited if you have node 20 installed already or don't use nvm
nvm install 20 && nvm use 20 && nvm alias default 20

# can be ommitted if you already have pnpm and turbo installed globally
npm install -g [email protected] [email protected]

pnpm install
turbo build --filter codemod

cd apps/cli && pnpm coverage

📄 Documentation to Update

[vercel[bot]]

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

A member of the Team first needs to authorize it.

[pkg-pr-new[bot]]

Open in Stackblitz

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

commit: 47d480e

[vercel[bot]]

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

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
codemod	⬜️ Ignored (Inspect)	Visit Preview		Feb 17, 2025 0:24am

[mohab-sameh]

@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]

@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.

[spirulence]

@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/@[email protected]/node_modules/@ast-grep/napi-linux-x64-gnu/ast-grep-napi.linux-x64-gnu.node
./node_modules/.pnpm/@[email protected]/node_modules/@rollup/rollup-linux-x64-musl/rollup.linux-x64-musl.node
./node_modules/.pnpm/@[email protected]/node_modules/@rollup/rollup-linux-x64-gnu/rollup.linux-x64-gnu.node
./node_modules/.pnpm/@[email protected]/node_modules/@next/swc-linux-x64-gnu/next-swc.linux-x64-gnu.node
./node_modules/.pnpm/@[email protected]/node_modules/@next/swc-linux-x64-musl/next-swc.linux-x64-musl.node
./node_modules/.pnpm/@[email protected]/node_modules/@msgpackr-extract/msgpackr-extract-linux-x64/node.napi.musl.node
./node_modules/.pnpm/@[email protected]/node_modules/@msgpackr-extract/msgpackr-extract-linux-x64/node.napi.glibc.node
./node_modules/.pnpm/@[email protected]/node_modules/@msgpackr-extract/msgpackr-extract-linux-x64/node.abi115.musl.node
./node_modules/.pnpm/@[email protected]/node_modules/@msgpackr-extract/msgpackr-extract-linux-x64/node.abi115.glibc.node
./node_modules/.pnpm/@[email protected]/node_modules/@prisma/engines/libquery_engine-debian-openssl-3.0.x.so.node
./node_modules/.pnpm/[email protected]/node_modules/keytar/build/Release/keytar.node
./node_modules/.pnpm/@[email protected]/node_modules/@ast-grep/napi-linux-x64-musl/ast-grep-napi.linux-x64-musl.node
./node_modules/.pnpm/[email protected]/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 https://github.com/codemod-com/codemod/blob/e8d1ca3aa12ef1fb7b49f8db193f449f57d353cb/.github/workflows/test.yml#L53

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

[spirulence]

This PR is quite out of date by now - closing.

[alexbit-codemod]

Thanks again for your time and contribution. We have now a new rust CLI and hope you find much value in it. 🙏🏼🍻