Skip to content

Conversation

@obemu
Copy link
Contributor

@obemu obemu commented May 27, 2025

Prepend '--no-version-check' so that Flutter CLI tool does
not look for a new version.

Executing any command with the Flutter CLI tool makes the tool look
for a new version and optionally prints this banner:

┌─────────────────────────────────────────────────────────┐
│ A new version of Flutter is available!                  │
│                                                         │
│ To update to the latest version, run "flutter upgrade". │
└─────────────────────────────────────────────────────────┘

The problem is that this banner causes errors when parsing the
output of the running command. To fix this, we omit the version
check by default, but give the user the option to enable it.

@sidlatau
Copy link
Collaborator

Hi @obemu,
Thank you for this PR and for tackling the issue with the Flutter upgrade banner.
I've also seen this banner. Yes, it causes parsing error once, but I do find the update notification itself helpful.
I've been exploring a potentially more general solution for managing such CLI output in PR:

Could you please take a look at #471 when you have a chance and let me know if that approach might also work for you?
Thanks again for your contribution!

@obemu
Copy link
Contributor Author

obemu commented May 28, 2025

@sidlatau #471 seems like a good and future-proof (in case of any other banners/caveats) approach for this issue. However, I think it can be improved by having separate global_run_options, one for flutter and the other for dart projects, because the Flutter and Dart CLI tools do not have the same options. This could be implemented like this:

In lua/flutter-tools/config.lua:

local config = {
  ...
  global_run_options = {
    --- Flutter project specific global run options, which will be passed to the Flutter CLI tool.
    flutter = nil,
    
    --- Dart project specific global run options, which will be passed to the Dart CLI tool.
    dart = nil,
  },
  ...
}

In lua/flutter-tools/commands.lua:

local function run(...)    
    ...
    
    local global_run_options = nil
    if is_flutter_project then
      ui.notify("Starting flutter project...")
      global_run_options = config.global_run_options.flutter
    else
      ui.notify("Starting dart project...")
      global_run_options = config.global_run_options.dart
    end

    if global_run_options then
      if type(global_run_options) == "string" then
        vim.list_extend(args, vim.split(global_run_options, " "))
      elseif type(global_run_options) == "table" then
        vim.list_extend(args, global_run_options)
      end
    end
    
    ...
end

@obemu
Copy link
Contributor Author

obemu commented May 28, 2025

Also on another note

..., but I do find the update notification itself helpful. ...

I, too, think that the update notification is not entirely useless. However, If you really wish to keep it, then I reckon we must find a solution to tell the user via vim.notify that there is a new Flutter version instead of letting a command like FlutterRun complete with an error.

@sidlatau
Copy link
Collaborator

@sidlatau #471 seems like a good and future-proof (in case of any other banners/caveats) approach for this issue. However, I think it can be improved by having separate global_run_options, one for flutter and the other for dart projects, because the Flutter and Dart CLI tools do not have the same options.

Yes, separating flutter and dart configs for default_run_args is more flexible solution, updated the PR.
So to achieve the same output as this PR this configuration may be used:

{
  default_run_args = { flutter = "--no-version-check" }
}

I, too, think that the update notification is not entirely useless. However, If you really wish to keep it, then I reckon we must find a solution to tell the user via vim.notify that there is a new Flutter version instead of letting a command like FlutterRun complete with an error.

I created separate issue for this one: #473

@sidlatau
Copy link
Collaborator

Closing the PR, as we found I think more flexible solution there: #471

Thanks again for helping to improve this plugin!

@sidlatau sidlatau closed this May 28, 2025
@obemu obemu deleted the feat-no_version_check branch July 14, 2025 12:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants