Skip to content

Survey code to determine scope of breaking project root assumption #5291

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

Open
stevemessick opened this issue Feb 26, 2021 · 6 comments
Open
Labels
code-health ide-consistency Issues where we are not up to date with IDE tech debt usability
Milestone

Comments

@stevemessick
Copy link
Member

We have a few requests that the Flutter project root directory be separated from the IntelliJ project directory. Actually, I think IntelliJ considers a project to be a collection of modules, independent of their location. That is, the modules do not have to share a common parent directory. One example is #5150.

We need to survey the code base to find where we assume the Flutter project root is the top-level directory in the project.

@shinayser
Copy link

Hope this get's fixed soon. Flutter projects are starting to become more complex every day and the necessity of a multi module support on the tooling side is a must. Here is a example of a problem I found when trying to perform tests on multi module projects: #5388 (comment)

@benoitskipr
Copy link

benoitskipr commented Oct 13, 2021

one of the assumptions seems to be the option to open Xcode from the right-click menu.
on monorepos, it always opens the first flutter project/module, disregarding the one we've actually right-clicked on.
and as it's not very clear in xcode, you can lose quite some time until you figure out you're in the wrong project.
making the 'open in xcode' option worthless, because you then have to open the right project manually inside xcode.

@krispykalsi
Copy link

I solved #5388 by adding each package directory as a content root. Here's how to do it (works on v2021.3) -

image
Source
Also, make sure to remove the parent directory as a content root before adding the child directories as one.

@westito
Copy link

westito commented Dec 13, 2021

I found a simple solution for this. Open the module settings of a multi-module project and remove the existing module (that is the root folder). After, add sub-project folders as new module (import). In importing dialog only select folders recognized as Flutter/Dart module. Flutter plugin will recognise these modules and enable Flutter features, tool windows.
Flutter plugin search things in modules, not directories. It's irrelevant where the Flutter/Dart project located if added as module.
Képernyőfotó 2021-12-13 - 18 36 47

@westito
Copy link

westito commented Dec 13, 2021

Another solution is: Instead of simply open the project folder (remove all .idea folders and *.iml files if your project folder already opened before), click New -> Project from Existing Sources. Select the root directory that contains sub-projects. Leave selected the Create project from existing sources radio button. Next -> Next -> untick unrelated modules (for ex. Android ones) and leave checked modules recognised as Flutter or Dart. Next. Importer says 'No frameworks detected'. That's normal. Click Finish. Voilà! You have the right modules and all of your sub-projects. That's all

@MilkBiscuit
Copy link

MilkBiscuit commented Feb 28, 2025

I have the same problem, Android Studio does not recognise the flutter project in a sub-folder.

Flutter projects have too many files and folders, I prefer to keep git, .github, images_backup, README.md, ReleaseNotes.md, TODO.md these files outside.

It used to work before, one day it stopped working (after upgrading Android Studio version I think).

Tried the two methods @westito mentioned, no luck, it's been 3 years, I don't find New -> Project from Existing Sources option in Android Studio...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code-health ide-consistency Issues where we are not up to date with IDE tech debt usability
Projects
None yet
Development

No branches or pull requests

6 participants