Gts lint returning exit code 1 when using yarn 4.0.2

[matheusr-ciandt]

The gts lint command is returning exit code 1 using yarn 4.0.2

➜ yarn --version        
4.0.2

➜ yarn lint 
version: 18

Using npm:

➜ npm run lint    

> <project>@0.0.1 lint
> gts lint

version: 18

/Users/matheusr/Documents/<project>/src/main.ts
  14:1  error  Delete `⏎··⏎`                prettier/prettier
  15:1  error  Trailing spaces not allowed  no-trailing-spaces

✖ 2 problems (2 errors, 0 warnings)
  2 errors and 0 warnings potentially fixable with the `--fix` option.

[vladavoX]

Same issue, as of version 5.1.0. At version 5.0.1 it works

yarn --version
3.6.3

yarn lint
version 18

[DMBerlin]

Lint was failing on a pipeline I had setup on the workflows.

Had to downgrade gts from "5.2.0" to "5.0.1" and it worked.

[linusjf]

Same problem here. Why is gts printing 'version 21' and returning exit code 1 when linting? Also, same exit code and printing out error on fixing. Why? (New to gts).

Not with yarn. Running gts as executable installed through npm.

[tonycoco]

Can you send me some steps to reproduce? I'm able to fresh install:

$ yarn init
$ npx gts init
$ yarn lint

Runs without any issues.

[linusjf]

I've abandoned my attempt to use gts at the moment. You can try my repo at https://github.com/linusjf/LearnSolidJS to see if you can recreate the problem. The only other thing you might need to know is that eslint was installed globally as ~v9.1.

[tonycoco]

@linusjf I was able to get it running on your repo by:

$ yarn
$ rm eslint.config.cjs
$ npx gts init
$ yarn lint

...works.

[tonycoco]

If I can ask: What version of Node are you running?

$ node -v

[linusjf]

Version 21.6.2

[linusjf]

@linusjf I was able to get it running on your repo by:

$ yarn
$ rm eslint.config.cjs
$ npx gts init
$ yarn lint

...works.

I'd rather use the new flat-config.

Perhaps, once gts moves to the new config, I'll look at it again.

#830

I'm already using prettier on my files, anyway, via the lint command line script.

[tonycoco]

Once we drop support for older versions of Node, I plan on migrating to the latest ESLint and will provide the flat config in the init. Closing this for now since we are tracking this already in #830

[nex3]

I've been struggling with this on gts 5.3.1 and here's what I've found. ESLint errors are silenced by the CLI. That's why this isn't reporting any error messages here. The specific error is

Error: Command failed with ENOENT: eslint **/*.ts **/*.js **/*.tsx **/*.jsx --no-error-on-unmatched-pattern
spawn eslint ENOENT
    at ChildProcess._handle.onexit (node:internal/child_process:286:19)
    at onErrorNT (node:internal/child_process:484:16)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'spawn eslint',
  path: 'eslint',
  spawnargs: [
    '**/*.ts',
    '**/*.js',
    '**/*.tsx',
    '**/*.jsx',
    '--no-error-on-unmatched-pattern'
  ],
  originalMessage: 'spawn eslint ENOENT',
  shortMessage: 'Command failed with ENOENT: eslint **/*.ts **/*.js **/*.tsx **/*.jsx --no-error-on-unmatched-pattern\n' +
    'spawn eslint ENOENT',
  command: 'eslint **/*.ts **/*.js **/*.tsx **/*.jsx --no-error-on-unmatched-pattern',
  escapedCommand: 'eslint "**/*.ts" "**/*.js" "**/*.tsx" "**/*.jsx" --no-error-on-unmatched-pattern',
  exitCode: undefined,
  signal: undefined,
  signalDescription: undefined,
  stdout: undefined,
  stderr: undefined,
  failed: true,
  timedOut: false,
  isCanceled: false,
  killed: false
}

...which suggests that gts is expecting eslint to be added to the PATH and it's not. Manually inspecting the path, I can confirm that under npm run it has a number of node_modules/.bin directories that don't exist when running under Yarn. I'm not familiar enough with Yarn to say what the expected solution is (although it seems like this was at one point supposed to work).

@tonycoco I think the reason you weren't able to reproduce this in #847 (comment) is that you have an eslint executable somewhere in your global PATH. I can reproduce on a clean package:

$ yarn init
$ yarn set version 4.4.1
$ yarn add gts
$ yarn run gts init -y # Note that this produces an unrelated error
$ yarn run gts lint
version: 22
$ echo $?
1

One possible mitigation is to use the npm-run-path module to guarantee that the PATH variable is configured to include the correct paths.

[nex3]

I confirmed on the Yarn Discord that the intended Yarn behavior is to provide access to dependency executables on PATH, and filed yarnpkg/berry#6485 to track this.