Monorepo setup: .cache file is created at the top level

[tordans]

In my github repo, I have my app in a sub folder and that holds the node_modules.
The top level folder does not have a node_modules.
When I rund the new cli in this app folder, the .cache is created in a new top level node_modules folder which I then see as a change in git:

[43081j]

good catch

in repos which aren't JS projects at the root, it doesn't make sense to use node_modules as the cache location 🤔

im not sure what we should fall back to in that case. lets see what @fabiospampinato thinks

[tordans]

in repos which aren't JS projects at the root, it doesn't make sense to use node_modules as the cache location 🤔

In my mind the issue is more that the cli does not use the right root as reference. I ran the script from inside /app which is where the package.json is. That should be the root for the /node_modules-(cache-)path.

[ratijas]

in repos which aren't JS projects at the root

why are we talking about repos at all? What version control system has to do with any of this node ecosystem / workspace?

[43081j]

because we want to store the cache in node_modules but not all projects are node projects, hence this problem here.

sounds like we should just use {cwd}/node_modules rather than traversing upwards or some such thing

[ratijas]

npm as such has built-in support for workspaces these days. You don't need to guesstimate.

https://docs.npmjs.com/cli/v11/using-npm/workspaces

[43081j]

there's no guessing happening here. the problem is that if the project isn't an node project, it won't have a node_modules. its possible to have sub-directories containing JS in a C# project for example.

this doesn't seem like a workspace thing, its just the fact not all node projects are top-level

so the fix is likely that we should use {cwd}/node_modules rather than traversing

[tordans]

Still curious about this part #80 (comment)

[ratijas]

its just the fact not all node projects are top-level

top-level of what? What is your reference point, and why is it git?

[43081j]

it isn't.

none of this is anything to do with git. i think you're misinterpreting something here, probably this:

which I then see as a change in git

he sees it as a change in git because the .gitignore will be ignoring his subdir's node_modules and not the root one, presumably. absolutely nothing to do with prettier.

the problem isn't that git shows this up, that's 100% unrelated. the problem is that the node_modules exists at all in the first place, at the root level.

let me reiterate, the sole problem here is this: not all projects are node projects at the top level (e.g. a C# project containing a subdir which has a node project in it). prettier seems to be creating node_modules/.cache at the top level rather than in the subdir. absolutely zero relation to git, it is just creating the cache dir one directory too high up the chain.

[ratijas]

So, for example, if somehow there were a node_modules directory in disk D:\ or at /home/, prettier would've attempted to write there?

Pardon me, but this is not exactly the case. I just reproduced the issue:

1. made sure to delete node_modules at the git repo's root: rm -Recurse -Force .\node_modules\
2. cd into subproject directory with package.json and node_modules
3. do pnpm run format which executes prettier --write --experimental-cli src/ *.config.ts
4. go back to root level
5. there is node_modules with sole prettier's cache file now.

with a fairly default .prettierrc.json config in subproject's directory:

{
  "$schema": "https://json.schemastore.org/prettierrc",
  "semi": false,
  "singleQuote": true,
  "printWidth": 100
}

[43081j]

So, for example, if somehow there were a node_modules directory in disk D:\ or at /home/, prettier would've attempted to write there?

no

the steps you've just listed are what i'm trying to communicate here:

prettier seems to be creating node_modules/.cache at the top level rather than in the subdir

"top level" here means top level of the project, not /.

the problem is fully understood at this point i think. it is unrelated to git, it is solely that prettier is creating a node_modules one directory too high in some cases.

[ratijas]

What is a project? If it's not a "closest directory that contains git", then what? Prettier just created node_modules in a directory where there were none before. I don't understand what are you keep referencing as "project" or "top level" or "too high"

[43081j]

if i create a project, an npm package called "foo" in /code/foo in my file system.

i call this a project. im not talking about anything programmatic here, conceptually, it is a project.

i think we are off on a needless tangent

there is a bug. the node_modules dir is created one level higher in the file system than was expected. that's all and we need to fix it, nothing to do with git, nothing to do with how we as humans define what a project is. its just making it in /code/foo rather than /code/foo/bar or whatever random setup we might have as a user.

it will be fixed once someone gets time to investigate.

[ratijas]

oh, so it's just going ../ from wherever it should've actually been, and it only happens in certain <unknown, todo: investigate> scenarios?