nvim-flutter / flutter-tools.nvim

Tools to help create flutter apps in neovim using the native lsp
MIT License
1.05k stars 84 forks source link

[BUG] Flutter project recognition not reliable #388

Closed TankOs closed 1 month ago

TankOs commented 2 months ago

Is there an existing issue for this?

Current Behavior

When the sdk: flutter line in my pubspec.yaml isn't formatted as expected by flutter-tools, it won't recognize my project as being a Flutter project, but instead launches with a Dart project configuration.

Expected Behavior

The detection of Flutter projects should work independently from how the pubspec.yaml is formatted. For example, if I use double quotes (sdk: "flutter"), then the project should still be detected as a Flutter project.

Steps To Reproduce

  1. Create a new Flutter project.
  2. In "dependencies.flutter.sdk", change flutter to "flutter".
  3. Try :FlutterRun. It will say "Starting Dart project..." instead of "Starting Flutter project...".

Environment

- OS: Arch Linux (updated 2024-09-10)
- Flutter version: 3.22.2
- Is flutter in $PATH: Yes, ~/bin/flutter/
- neovim version: v0.11.0-dev-700+gbcae8be91f with LuaJIT 2.1.1723675123

Anything else?

I think the detection code is not reliable (single quotes are also valid in YAML, and maybe tons of other ways). It's also possible to insert the expected string somewhere in the file, where it doesn't have any purpose, and still trigger the Flutter build.

madflow commented 1 month ago

The detection of Flutter yes/no is a regex: https://github.com/nvim-flutter/flutter-tools.nvim/blob/ea1d398f543a54ba95357c3b8bb9d6f68eaec36c/lua/flutter-tools/commands.lua#L206

I asked AI to allow quotes and it came up with:

  local is_flutter_pattern = "flutter%s*:%s*sdk%s*:%s*['\"]?flutter['\"]?"
  local flutter_dependency = string.match(joined_content, is_flutter_pattern)

This fixes the quotes I suppose - an actual yaml parser implementation would be argueably more robust.

TankOs commented 1 month ago

AI should have told you that any regexp is not reliable 😉, because you have no idea how YAML is going to progress in the future, and you won't be able to handle all existing solutions, even now. One might use YAML anchors or other fancy things already.