Repository navigation
flutter analyze behaviour with a command line argument is very confusing #7274
Description
It's not at all clear to me what happens when you run flutter analyze foo where foo is a path.
In particular:
- if the path is invalid we seem to just ignore it
- consider the differences here, where
tempcontains a single.dartfile, anddevis the directory that contains my flutter checkout dart sdk checkout, engine checkout, etc:
$ cd ~/temp
$ flutter analyze ../dev
Analyzing ../dev...
No analyzer warnings! (ran in 0.2s)
$ cd ~/dev
$ flutter analyze ../dev
Analyzing ....
No analyzer warnings! (ran in 0.2s)
$ flutter analyze
Analyzing 31030 files...
See also #4387 which may be contributing to the confusion.
Activity
Hixie commentedon Jan 13, 2017
@danrubel and I talked about this this morning and came to the following conclusion (I may have elaborated a bit from our discussion, let me know if I made any mistakes!):
--current-directorycommand line argument should be removed.pubspec.yamlfiles (all the "contexts") that we should then analyze. Directories that contain.dartignorefiles get skipped by this crawl. The analyzer further ignores files based on the relevant.analysis_optionsfiles.--flutter-repoargument is a shorthand for also listing the path of the root of the flutter repo.--current-packageargument is a shorthand for also listing the nearest enclosing directory going up from the current directory that contains apubspec.yaml.--flutter-reponor--current-packageare listed and there are not non-option arguments, default to the--current-packagebehaviour.danrubel commentedon Jan 13, 2017
Yes, this sounds good to me. I suggest we remove
--current-packageand make it the default behavior if no non-option arguments are supplied.danrubel commentedon Jan 13, 2017
Since
--flutter-repois shorthand for the flutter repo root path, I amend my current suggestion to be ...We remove
--current-packageand make it the default behavior if no non-option arguments are supplied and--flutter-repois not supplied.Hixie commentedon Jan 13, 2017
That would mean that you can't only scan the flutter repo, no?
danrubel commentedon Jan 13, 2017
Adding
--flutter-repowould be the same as adding/the/path/to/the/flutter/repo, and would be included with any other paths of files/directories to be analyzed. IOW, this is would analyze the flutter repo along with files in the other specified directories...flutter analyze --flutter-repo /my/first/project /my/second/projectAnd this would just analyze just the flutter repo regardless of the current working directory
flutter analyze --flutter-repoHixie commentedon Jan 13, 2017
The use cases my ideal world would support are:
--flutter-repo).I think if we don't have
--current-packageas a way to trigger the default behaviour even in the presence of other options, we can't get use case 4. If we always imply--current-package, we can't get use case 3.danrubel commentedon Jan 13, 2017
Updated my comment above to clarify using
--flutter-repowith no other arguments.Hmmm... fair enough. IOW
flutter analyzeandflutter analyze --current-packageare the same, but we continue to support--current-packageso that you don't have to explicitly specify the path of the project containing the current directory when specifying multiple targets.For example
flutter analyze --flutter-repo --current-package /path/to/yet/another/projectwould analyze......all at the same time.
Hixie commentedon Jan 13, 2017
Right.
In theory the argument should be almost trivial to support since it's just a way to trigger the default behaviour. It also makes it easier to "explain" what the default behaviour is.
xster commentedon Jan 23, 2017
My clueless new guy 2-cents. I ran into this looking at the onboarding guides and was a bit confused with the difference between [no-arguments], flutter-repo, current-directory, current-package.
The first line of the doc says "Analyze the project's Dart code". Agree with comment 272536360 that --current-package is then implied if no arguments are supplied. Seems like --current-directory is redundantly a strict subset of --current-package. Less options/reading for the user, the better I think :)
re:flutter-repo. Had to re-read it a few times. Initially I was thinking, wouldn't all the packages you want to analyze in some flutter-based repo? But I guess this is referring to the tool/framework repo. Is this special enough for our users to have a special option flag? Most people would just do brew install flutter and never look at that tool/framework repo again right?
For foolproof understandings, maybe we can avoid mixing directories and option flags by having no option flags be shorthands for directories. e.g.
1- flutter analyze -> current package
2- flutter analyze x -> recursively x only
3- flutter analyze . x -> recursively current directory and x
4- flutter analyze $FLUTTER_ROOT -> recursively the flutter framework repo only
This way, flags are all instructions on how to run flutter analyze, not a mixture of how to run and what to run on.
4 makes it a bit more painful for us (framework contributors) but we're such a command doc reader minority that clarity overweight our convenience.
Hixie commentedon Jan 23, 2017
I'm fine with hiding
--flutter-repofrom the--helplisting, but it is hugely useful to the team and that's important to Flutter's ability to evolve, so I think we should keep it.HansMuller commentedon Jan 24, 2017
I agree with Ian. I use
--flutter-repoall the time and wouldn't mind if it didn't appear in the--helplisting.8 remaining items
tmaihoff commentedon Oct 5, 2021
I have a similar issue.
I want to analyze only the lib folder with
flutter analyze lib.However, problems inside
examplewhich is a sibling folder are still foundbkonyi commentedon Sep 30, 2024
The issues mentioned here all seem to be resolved based on some quick tests.
github-actions commentedon Oct 14, 2024
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.