AstroNvim
Typescript Pack ( root_has_file ) issues with Superproject and Submodule Architecture
Checklist
- [X] I have searched through the AstroNvim docs
- [X] I have searched through the existing issues of AstroNvim
- [X] I have searched the existing issues of plugins related to this issue
Neovim version (nvim -v)
0.9.1
Operating system/version
macos 13.5.2
Terminal/GUI
kitty
Describe the bug
Hello There,
When having a "Superproject" with several Submodules, the root_has_file seems to resolve the root directory of the Superproject which might not even be a Nodejs/Js Project.
So in this case Prettier or Eslint only work when defined in the package.json, since they are resolved relative to the current working directory.
Why is resolving of the eslint and prettier config implemented different for package.json and config files? Wouldn't it make sense to resolve them relative to the cwd as well?
Steps to Reproduce
mkdir test_ts_pack cd test_ts_pack/ mkdir inner cd inner npx create-next-app@latest nvim .
Expected behavior
eslint_d will not start
adding config to eslintConfig prop in package.json will start eslint_d
Screenshots
No response
Additional Context
No response
I think for now the only way is to use the package.json properties, since package.json is referenced relative to the cwd. Or configure everything manually and avoid using the ts pack, basically copy and paste their config and dont use root_has_file function.
sorry about the silence, been a stressful week. I'll have to take a look at the issue more closely, especially the original PR before I comment on the issue here.
Could we get a more real life example? I feel like the example given is "too far fetched". I can't see the utility of it. This might not actually be an issue that's due to how eslint/prettier is setup, but it could also have something to do with how the root folder is detected for the project outside of the methods used in the community plygin(using .git folder, or other files)
This is coming from a real life example...
It is common sense to have submodules in a project. Submodules are git repos. Ergo this does not work with submodules that use prettier or eslint.
And i would imagine that Monorepos would fail either.
My example was just a very simplified version of that, to reproduce the issue.
This is coming from a real life example...
It is common sense to have submodules in a project. Submodules are git repos. Ergo this does not work with submodules that use prettier or eslint.
And i would imagine that Monorepos would fail either.
My example was just a very simplified version of that, to reproduce the issue.
Most of my projects are monorepos. I used to use the community pack with those and I never had an issue, and the pack has changed minimally since then.
Do you have a github repo with the submodule architecture you've described I can test on?
Yes, here the repo where it fails: https://github.com/leihs/leihs
the procure submodule is the npm project
Ah now I get the issue. A new PR with vscode-eslint-lsp solves the eslint side of this problem.
@belafonte @NesterenkoDanil @nochzato Does #600 solve the issue at the eslint side?
Sorry for replying late... Had no chance to test it earlier. But yes i can confirm, that eslint does work now!
Great thank you.
Let me know if this is still an issue and I can reopen, but should be resolved now!
