Skip to content

Support SDK per module #5767

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

Closed
xuanswe opened this issue Sep 19, 2021 · 6 comments
Closed

Support SDK per module #5767

xuanswe opened this issue Sep 19, 2021 · 6 comments

Comments

@xuanswe
Copy link

xuanswe commented Sep 19, 2021

Assuming we have an IntelliJ project with multiple modules.
Each IntelliJ module is a flutter project and they depend on different SDK versions.

Currently, we can only specify single Flutter SDK path per IntelliJ project.
Each time, we want to switch to work on other module, we need to change the channel/branch of the shared SDK path.

It would be nice if beside the default flutter configuration per project, we can overwrite this configuration per each module. It's similar to specifying different Java SDK for each module.

@stevemessick
Copy link
Member

If FVM features are adopted by the Flutter SDK then we will support them.

@xuanswe
Copy link
Author

xuanswe commented Sep 22, 2021

If FVM features are adopted by the Flutter SDK then we will support them.

@stevemessick I am not sure if we misunderstood each other.

  • In case you misunderstood my first description:

    I am not talking about supporting FVM. I only mention FVM as an example of how we can nowaday manage different flutter SDKs on the same machine for different flutter projects.

    I update the description to avoid misunderstanding.

  • In case I misunderstood your sentence:

    Do you mean, Flutter team plans to implement similar features in the future natively? If yes, do you have link to that issue?

@xuanswe
Copy link
Author

xuanswe commented Oct 13, 2021

@stevemessick do you consider to reopen this issue or give more details about working with multiple Flutter versions at the same time?

@stevemessick
Copy link
Member

Thanks for the update. You're asking for support of monorepo projects. That's tracked in #5291. There are a couple issues related to that. Search for "monorepo" (including closed issues) for more info. We are working on it, but a lot of other things keep getting prioritized over it. I'd like to think that each Flutter module in a monorepo project would have naturally had its own SDK; now that you've brought it up we can make sure it does.

For now, you will get the best Flutter coding experience by opening each Flutter project in its own top-level IntelliJ project. I use multiple windows and use a keystroke to switch between them.

@xuanswe
Copy link
Author

xuanswe commented Oct 13, 2021

Thank you for the info!

I'd like to think that each Flutter module in a monorepo project would have naturally had its own SDK.

Yes, each flutter module should have its own SDK.

For now, you will get the best Flutter coding experience by opening each Flutter project in its own top-level IntelliJ project. I use multiple windows and use a keystroke to switch between them.

For now, it's the only way to work with different Flutter SDKs at the same time.
There are some disadvantages, but we need to accept for the time being:

  • cannot search in multiple flutter projects
  • need multiple clicks to open/close these related projects
  • annoying when too many windows are mixing with other applications' windows.
  • etc.

@stevemessick
Copy link
Member

Those are valid concerns, which we want to address in monorepo support. However, I think you can work around one of them

cannot search in multiple flutter projects

If you open the top-level (monorepo) project in its own window, and in that project mark each lib directory in each module as a sources root then I think you will be able to search all Flutter projects. I don't promise this will work, but it should.

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

No branches or pull requests

2 participants