🐛 Invalid line/column calculating in Vue files

[maximal]

Environment information

CLI:
  Version:                      1.8.3
  Color support:                true

Platform:
  CPU Architecture:             aarch64
  OS:                           macos

Environment:
  BIOME_LOG_DIR:                unset
  NO_COLOR:                     unset
  TERM:                         "xterm-256color"
  JS_RUNTIME_VERSION:           "v22.4.0"
  JS_RUNTIME_NAME:              "node"
  NODE_PACKAGE_MANAGER:         "bun/1.1.18"

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

Workspace:
  Open Documents:               0

What happened?

Hi!

I’m working on integrating Biome to my Code Quality Generator (@maximal/gitlab-code-quality#6) and faced an issue of invalid issue location calculating in Vue files when using --reporter=github.

Seems like Biome shows lines/columns relative to <script> position inside of the file, and not relative to the beginning of the file. Which makes almost impossible to highlight issues in GitLab CodeQuality widget and other similar instruments.

Expected result

Calculate lines and columns regarding to the beginning of the Vue file, and not regarding <script> section contents.

Code of Conduct

• [X] I agree to follow Biome's Code of Conduct

[dyc3]

Yeah, this is kind of a limitation of how we currently support HTML-ish template languages (see also: #1726) like vue, svelte, and others. Basically, we kinda regex for where the javascript code actually is in those files, and then just format/lint that code instead of the entire file. It's very hacky.

https://github.com/biomejs/biome/blob/08f0c8f1078d31ec5764532dccfeec84146560f1/crates/biome_service/src/file_handlers/vue.rs#L28-L30

Its technically possible to figure out the line offset of the script tag and then tweak the output based on that offset. IMO, whatever the short term solution for this is, it's going to be rendered unnecessary once we have proper support for HTML-ish languages, and I'm not sure if its worth the additional complexity to do that.

[Superpat]

I'd like to a least voice support for a short term solution, though I understand that dev time is always limited. Unless proper html-ish support is right around the corner, it's going to remain a pain point for whoever uses tools that allow jumping from a file:line:char to the proper location in the editor.

[ematipico]

We already fix this information inside our LSP, so I don't see why we shouldn't do it here:

We generate an offset in the case of astro/svelte/vue files:

https://github.com/biomejs/biome/blob/48089eaeec03eac6f5f471167b5d2ddb326ffae3/crates/biome_lsp/src/session.rs#L340-L344

And then we create a new TextRange is that offset was provided.

https://github.com/biomejs/biome/blob/48089eaeec03eac6f5f471167b5d2ddb326ffae3/crates/biome_lsp/src/utils.rs#L187-L197

In the case of our reporters, we just need to provide them with a new Location that contains the new TextRange.

I am happy to help anyone that wants to help to fix the bug, or wait for me to fix it.

[dyc3]

Oh, then in that case this probably isn't too hard to fix. I'll have time next week to fix this, but if someone wants to tackle it earlier please do.

[maximal]

Had I known Rust, I would’ve helped with a pull request, for now I’ll just wait (even though your code looks very clean) :-)