🐛 rome check . seems to run in an infinite loop with 99% CPU usage

[RobinMalfait]

Environment information

OS Information:
- macOS Monterey, version 12.5.1 (21G83)
- Apple M1 Max

Context:
- Wanted to play with the new version in Tailwind CSS to see how it behaves when running `rome format . --write` or `rome check .`

Installation:
- `npm install rome@next --save-dev`

Versions:
- Node: v18.8.0
- NPM: 8.18.0

What happened?

Every now and then when you release a new version, I try to play with it on a real codebase, in my case I'm playing with things in the Tailwind CSS codebase (https://github.com/tailwindlabs/tailwindcss).

I basically installed rome:

npm install rome@next --save-dev

... once that was done, I executed:

rome check .

It shows a bunch of output already, but then just hangs, and it looks like this:

When I looked at activity monitor I saw this:

I eventually had to quit rome by using ctrl+c and luckily that worked without me force killing the process.

Expected result

I would have expected that the command (rome check .) did its job and once it was done, that it exited the process successfully.

Code of Conduct

• I agree to follow Rome's Code of Conduct

[sebmck]

I think I encountered something similar. It occurs during console printing after the lint run has completed. In my case it was trying to format a huge multi-megabyte file. Does that sound similar to your situation?

[RobinMalfait]

Aha! Yep it's stuck on a 3.4 MB .js file. It's 116 281 lines of code long file. It's also a generated files so might be useful to ignore that one specific file.

Could be nice if Rome warned about large files and ignore them or ask you if it should be handled or not. Not sure, just thinking about improving the UX.

[leops]

We already have a file size threshold to avoid printing the diff to the console if it's over 1 MiB, so the fix for this could simply be to move this check earlier in the pipeline, probably before we even start parsing (and it would also benefit the Language Server to avoid hogging CPU and memory when a user opens a minified bundle in their editor). It may need some sort of escape hatch though, like an --ignore-size-limit flag on the CLI for users that really do want to reformat a minified bundle ...