Hi @theahura -

Thank you for the bug report.

I was able to replicate the issue on my end.

I think it is some incompatibility between eslint v8 and v9.

According to eslint docs for v9 [1] (emphasis mine):

This config system is feature complete but not enabled by default. To opt-in, place an eslint.config.js file in the root of your project or set the ESLINT_USE_FLAT_CONFIG environment variable to true.

and...

The ESLint configuration file is named eslint.config.js. It should be placed in the root directory of your project

Moving packages/app3/eslint.config.js to the root of my project resolves the issue.

Edit:

After digging further into eslint docs, I found this. So, in theory, it should detect eslint.config.js in the children sub-directories.

So, I think this issue is with how working directory gets resolved in ale for js/ts projects:

• for js files https://github.com/dense-analysis/ale/blob/master/ale_linters/javascript/eslint.vim#L8
• for ts files https://github.com/dense-analysis/ale/blob/master/ale_linters/typescript/eslint.vim#L7
• GetCwd definition:

  ale/autoload/ale/handlers/eslint.vim

  Lines 43 to 69 in 29e5ffe

  	function! ale#handlers#eslint#GetCwd(buffer) abort
  	" ESLint 6 loads plugins/configs/parsers from the project root
  	" By default, the project root is simply the CWD of the running process.
  	" https://github.com/eslint/rfcs/blob/master/designs/2018-simplified-package-loading/README.md
  	" https://github.com/dense-analysis/ale/issues/2787
  	"
  	" If eslint is installed in a directory which contains the buffer, assume
  	" it is the ESLint project root. Otherwise, use nearest node_modules.
  	" Note: If node_modules not present yet, can't load local deps anyway.
  	let l:executable = ale#path#FindNearestExecutable(a:buffer, s:executables)
  	if !empty(l:executable)
  	let l:modules_index = strridx(l:executable, 'node_modules')
  	let l:modules_root = l:modules_index > -1 ? l:executable[0:l:modules_index - 2] : ''
  	let l:sdks_index = strridx(l:executable, ale#path#Simplify('.yarn/sdks'))
  	let l:sdks_root = l:sdks_index > -1 ? l:executable[0:l:sdks_index - 2] : ''
  	else
  	let l:modules_dir = ale#path#FindNearestDirectory(a:buffer, 'node_modules')
  	let l:modules_root = !empty(l:modules_dir) ? fnamemodify(l:modules_dir, ':h:h') : ''
  	let l:sdks_dir = ale#path#FindNearestDirectory(a:buffer, ale#path#Simplify('.yarn/sdks'))
  	let l:sdks_root = !empty(l:sdks_dir) ? fnamemodify(l:sdks_dir, ':h:h:h') : ''
  	endif
  	return strlen(l:modules_root) > strlen(l:sdks_root) ? l:modules_root : l:sdks_root
  	endfunction

In short, the GetCwd should probably look for config file markers, instead of node_modules directories.

@theahura - by any chance, have you read the docs about nested eslint configurations?

I was able to resolve the issue on my end without ale code changes, by updating the eslint config file like:

module.exports = {
    // redacted for brevity

    "extends": [
        "../../eslint.config.js" // to extend the root eslint.config.js
    ],

    // redacted for brevit
}

I've read those docs before, but I don't follow what the suggestion is. Just to confirm, is the suggestion to have an eslint config at root AND an extension in each app folder?
So something like:

foo/
  eslint.config.js
  node_modules/eslint
  packages/
    app1
    app2
    app3/
      eslint.config.js

?
Previously for brevity I left out a bit of how our folders are structured, but it may be worth clarifying here. Our configs are also part of packages, so our actual folder structure looks like this:

foo/
  configs/
     root-estlint-config.js
  packages/
     app1/
        eslint.config.js
     app2/
        eslint.config.js

Each package/eslint.config.js looks something like this (pulling an actual examples)

const configs = require('@foo/configs.soot-style');

module.exports = [
  ...configs.eslint,
  {
    files: ['codegen/plugins/**/*.js'],
    rules: {
      '@typescript-eslint/no-var-requires': 'off',
    },
  },
];

so we actually are inlining the full root eslint config here

Just leaving a comment here because I have run into the exact same issue with a similar setup.

If you have an idea how to fix this let me know your thoughts - perhaps I can have a go at implementing.

Something like this perhaps #4637

The Vader tests are a rabbit whole I can't really figure out ATM (happy for any guidance).

In the meantime I have added the following hack to $MYVIMRC - incase someone else finds this thread it is working for my mono repo setup:

augroup TypeScriptOverrides
    autocmd!
    autocmd BufRead,BufNewFile *.ts,*.tsx,*.js,*.json call s:DefineEslintFunction()
augroup END

function! s:DefineEslintFunction()
  function! ale#handlers#eslint#GetCwd(buffer) abort
      " Obtain the path to the ESLint configuration
      let l:config_path = ale#handlers#eslint#FindConfig(a:buffer)
  
      " Extract the directory from the config path
      let l:config_dir = fnamemodify(l:config_path, ':h')
  
      " Return the directory as the cwd
      return l:config_dir
  endfunction
endfunction

I'm having the same problem. PLEASE provide an escape hatch / option override for evaluating cwd!!

Please! Please! Please!

For context, the reason the current current directory logic does not work for my specific monorepo is that our project uses Yarn workspaces. The system does not add monorepo wide executables to each workspace's node_modules but instead they go in the repos top node_modules thus the logic to find the executable walks up the monorepo tree till it finds the monorepo root. But eslint needs the current working directory to capture workspace eslint configs.

@bodymindarts workaround does the job for my use case. It is unfortunate it needs such a sledge hammer approach though.

I just discovered that even in a yarn workspace running from the top level will still process configs down the chain as it resolves them from the --stdin-filename and walks backwards. This might be a quirk of eslint which makes running from root OK. Maybe the workaround is unneeded in this specific use case?

I seem to have run into this issue again, unexpectedly on a new machine. I have no idea how I fixed the old machine, whoops. @bodymindarts any chance of reviving that PR that you were working on earlier?

I am getting a slightly different error now than the one i was getting when I first filed the report -- namely, Parsing error (You may need configure typescript-eslint-parser) -- but the rest of the symptoms are the same. When I run eslint in the right folder, I get no errors; when I run it from wherever ale is trying to run it (i.e. the eslint node_module folder), all the errors

Got it! I had a rogue .eslintrc file in my home directory, deleting that fixed it for me (both the original time and this time)