Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🐛 Unexpected error when running biome check --apply-unsafe #459

Closed
1 task done
beccauwu opened this issue Sep 30, 2023 · 3 comments · Fixed by #595
Closed
1 task done

🐛 Unexpected error when running biome check --apply-unsafe #459

beccauwu opened this issue Sep 30, 2023 · 3 comments · Fixed by #595
Labels
A-Linter Area: linter S-Bug-confirmed Status: report has been confirmed as a valid bug S-Help-wanted Status: you're familiar with the code base and want to help the project

Comments

@beccauwu
Copy link

Environment information

CLI:
  Version:                      1.1.0
  Color support:                true

Platform:
  CPU Architecture:             x86_64
  OS:                           linux

Environment:
  BIOME_LOG_DIR:                unset
  NO_COLOR:                     unset
  TERM:                         "xterm-256color"
  JS_RUNTIME_VERSION:           unset
  JS_RUNTIME_NAME:              unset
  NODE_PACKAGE_MANAGER:         unset

Biome Configuration:
  Status:                       Loaded successfully
  Formatter disabled:           false
  Linter disabled:              false
  Organize imports disabled:    true
  VCS disabled:                 true

Workspace:
  Open Documents:               0

Discovering running Biome servers...

What happened?

As title says - i ran biome check ./src --apply unsafe and got the following printed out:

$ biome check ./src --apply-unsafe
Biome encountered an unexpected error

This is a bug in Biome, not an error in your code, and we would appreciate it if you could report it to https://github.com/biomejs/biome/issues/ along with the following information to help us fixing the issue:

Source Location: /home/runner/work/biome/biome/crates/biome_rowan/src/ast/mod.rs:230:13
Thread Name: rome::worker_9
Message: Tried to cast node with kind JSX_STRING as `"biome_js_syntax::generated::nodes::AnyJsExpression"` but was unable to cast

To add to the env information i'm using bun 1.0.3 in case that's relevant.

The command has worked previously without issue though, not sure what's up this time. From what I can tell it seems to have applied everything as normal this time as well - vscode shows files I haven't touched as modified as per my config

Expected result

Not the bug printout

Code of Conduct

  • I agree to follow Biome's Code of Conduct
@Conaclos
Copy link
Member

Conaclos commented Oct 1, 2023

Did the error arises if you call biome format --write ./src? biome check --apply ./src?

Could you identify which file that produces the error? The issue should come from a file with JSX elements.

@ematipico ematipico added S-Needs response Status: await response from OP A-Linter Area: linter S-Bug-confirmed Status: report has been confirmed as a valid bug labels Oct 2, 2023
@beccauwu
Copy link
Author

beccauwu commented Oct 3, 2023

Did the error arises if you call biome format --write ./src? biome check --apply ./src?

Could you identify which file that produces the error? The issue should come from a file with JSX elements.

sorry for getting to this a bit late! I ran your suggestions

  • biome format --write ./src works fine

  • check --apply ./src shows no error but gets stuck with no output

I then went through tsx files with --apply-unsafe to see if any specific file was causing this and one showed the same bug output as I got previously.

It seems to have something to do with fragments after a condition on the same line? I did some experimenting:

//all these work:
{'' != null && <div>stuff</div>}
<>{'' != null && stuff}</>
{<>stuff</>}

//this gives error
{'' != null && <>stuff</>}

There were two lines with the format that gave the error in the file.

@Conaclos
Copy link
Member

Conaclos commented Oct 3, 2023

Thanks! This will greatly help!

The issue is certainly coming from noUselessFragments. If you disable this rule, do you still encounter the problem?

EDIT: I think I got the bug. The rule replaces the fragment by a JSX_STRING in a JavaScript string expression.
In this particular case, I think we should not remove the fragment because it is the root node of the JSX expression. I am not a React expert. I could appreciate comments on this.

@Conaclos Conaclos added S-Help-wanted Status: you're familiar with the code base and want to help the project and removed S-Needs response Status: await response from OP labels Oct 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Linter Area: linter S-Bug-confirmed Status: report has been confirmed as a valid bug S-Help-wanted Status: you're familiar with the code base and want to help the project
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants