OOM issue when running ESLint command via Nx about nx HOT 7 CLOSED

Just to add more context -- I'm not using any ESLint-related Nx plugins. The monorepo is maintained in the package-based approach. This is why it's even more surprising to see that running a custom command works, but wrapping it with Nx leads to an OOM error.

from nx.

@akwodkiewicz Can you share a repro on this?

from nx.

Unfortunately I cannot at the moment, because this is a private company monorepo, so for obvious reasons I cannot just make it public. And I still was not able to find the minimal set of things that trigger this issue.

The monorepo has dozens of projects, but the OOM issue hits only the biggest one (>10k files). The project references other packages, both using proper imports and using TS's path aliases. I have some refactors planned that will change the TypeScript setup a bit -- my gut feeling says that it might contribute to the issue.

Apologies for not being able to provide more info at this moment, but I decided to file a issue anyway, because this is bugging me for a long time and I figured out that maybe the maintainers have some quick ideas or maybe somebody else will be able to provide a repro under this ticket.

If I'm able to give more info, I'll definitely update you on this one.

from nx.

I kept the parser: '@typescript-eslint/parser' setting in the root .eslintrc.yml file (otherwise ESLint fails on parsing .ts files even for type-less rules) but removed all @typescript-eslint/* rules from the configuration files.

It finished linting without OOM issues in 50s.

Before the changes ESLint would take around 4 minutes (if run without Nx, otherwise there was this OOM issue). So at least I know this is somehow related to TypeScript and @typescript-eslint behaviour.

from nx.

Anyway, I don't think that Nx modifies ESLint's behaviour in any way, since it's run without any Nx plugins, so it feels like it should be only about resources management.

Maybe there's some other info I could provide, related to, for example, memory usage and we could operate on that?

from nx.

I was able to mitigate the issue by moving the @typescript-eslint rules from one file to another.

The affected project is configured by 3 .eslintrc.yml files. 2 files contain a rules key that includes various @typescript-eslint entries. I kept all of the files, but moved all @typescript-eslint rules from the 2nd config file to the root config file.

.eslintrc.yml   <-------------------------.
packages/              merged this with that
    .eslintrc.yml    <----------'  
    affected-project/
        .eslintrc.yml

I need to properly use override instead of simply moving the rules to rules (because now the rules from packages started affecting projects that are not located in packages (yes, there are projects like that). But at least I was able to quickly find a weird difference in tooling behaviour.

from nx.

When I moved the rules from nested .eslintrc to overrides the issue came back.

I finally resolved it by upgrading @typescript-eslint packages from version 7 to version 8.

from nx.