[Feature Request] - Configure IDE path on "use" command

[leoafarias]

Problem:

Right now the user needs to manually configure their IDE path for VSCode in order to have all IDE tooling running properly. This causes some support issues to be opened, need to view the documentation, and also a less ideal Dev experience.

Solution:

When the developer does fvm use <version> fvm should automatically detect the IDE and configure the version if it has not been configured before.

VS Code:

• Look for the .vscode folder in the project
• Look for settings settings.json
• Look for dart.flutterSdkPath or dart.flutterSdkPaths
• If exists it should be ignored, if not it should set the path to <version>
• Should also configure all remaining settings as described here if they do not exist -> vscode config

Android Studio:

• Studio also creates a .idea folder however some research needs to be done if this can be created the same way as vscode or needs to be configured within the IDE itself.

[artificerchris]

I was actually coming to suggest this, but I just noticed, in the logs for the VSCode flutter extension, the extension looks for a flutter SDK at the root of the workspace in a folder called .flutter. I ran ln -s .fvm/flutter_sdk .flutter and upon re-opening my project, the editor found the sdk automatically! Maybe we could get an option in fvm use to link the SDK there instead of .fvm/flutter_sdk.

From the extension logs:

[8:33:23 PM] [General] [Info] Searching for flutter
[8:33:23 PM] [General] [Info]     Looking for flutter in:
[8:33:23 PM] [General] [Info]         /Users/username/Projects/project
[8:33:23 PM] [General] [Info]         /Users/username/Projects/project/bin
[8:33:23 PM] [General] [Info]         /Users/username/Projects/project/.flutter
[8:33:23 PM] [General] [Info]         /Users/username/Projects/project/.flutter/bin
[8:33:23 PM] [General] [Info]         /Users/username/Projects/project/vendor/flutter
[8:33:23 PM] [General] [Info]         /Users/username/Projects/project/vendor/flutter/bin
[8:33:23 PM] [General] [Info]         /Users/username/flutter-sdk
[8:33:23 PM] [General] [Info]         /Users/username/flutter-sdk/bin

[leoafarias]

That is a great suggestion. Do you want take a stab at it with a PR, it would be important to maintain both directories, to offer backwards compatibility, and provide a deprecation notice.

[artificerchris]

Any strong preference on it being a flag vs just the default behavior with a notice? I don't mind to make a PR, but it'll likely be this weekend if it's more than a simple change.

Edit:

Also, just looking, it looks like I'd want to add the link to updateSdkLink and maybe another synthetic property on FvmConfig for the path to the flutterToolsSdkPath? That's the best name I've come up with for it so far. (project_root/.flutter).

[leoafarias]

Yes I believe that makes sense... I suggest keeping more specific like flutterProjectSdkPath since we have the fvm path, and some others which are the cache version.

[leoafarias]

This has changed considerably for version 3.0, I believe on Vscode. this already is behaving correctly, but I am not sure what is the best approach to change the PATH on android studio.

[ManuelRauber]

@leoafarias I'm trying FVM 3.0 beta 5 and I've noticed, that the structure within the .fvm has been changed.

In the docs of FVM 2.x there is:

Copy the absolute path of fvm symbolic link in your root project directory. Example: /absolute-project-path/.fvm/flutter_sdk

As per FVM 3.0, there is no flutter_sdk folder anymore, the structure looks like:

.fvm
  - version
  - release
  - versions
    - 3.16.0

To make it work in Android Studio, I've to point it to an exact version, like /absolute-project-path/.fvm/versions/3.16.0.

While FVM still makes it easier to handle multiple Flutter versions, within a project each team member will have to change their paths.

It looks like that in Android Studio the paths are saved under .idea/libraries/Dart_SDK.xml and .idea/libraries/Dart_Packages.xml.

So, there are two possible solutions:

1. When fvm use is invoked, change the paths in those files.
2. Re-introduce a flutter_sdk folder that points to whatever version in .fvmrc.

[kuhnroyal]

Did you check the .fvm/version folder?

[ManuelRauber]

Did you check the .fvm/version folder?

What exactly do you mean?

version is a file.

ls -al
total 16
drwxr-xr-x   5 manuelrauber  staff   160 Nov 16 09:39 .
drwxr-xr-x  38 manuelrauber  staff  1216 Nov 16 11:57 ..
-rw-r--r--   1 manuelrauber  staff     6 Nov 16 09:39 release
-rw-r--r--   1 manuelrauber  staff     6 Nov 16 09:39 version
drwxr-xr-x   3 manuelrauber  staff    96 Nov 16 09:39 versions

[kuhnroyal]

Ah ok, thought this might be the new linked version folder, nvm.

[leoafarias]

@ManuelRauber I think adding the symlink to flutter_sdk might make sense, however I had the symlink resolve every time in my android studio setup. Also I am really interessted in changing the android studio path similar to what we are doing with vscode, is that something you can provide more insight, or maybe even do a rough PR that I can take over?

[ManuelRauber]

@leoafarias I can try to make a rough sketch if changing the paths in the .idea folder actually works.

[ManuelRauber]

@leoafarias Ok, I think it's easy to solve. :-)

I think we do not need to fiddle around with any paths. We only need the flutter_sdk symlink back.

I will use the Dart_SDK.xml as an example. It works the same with the Dart_Packages.xml file.

Initially, the Dart_SDK.xml file looks like this:

<component name="libraryTable">
  <library name="Dart SDK">
    <CLASSES>
      <root url="file://$USER_HOME$/fvm/versions/3.13.9/bin/cache/dart-sdk/lib/async" />
<!-- some more <root> things -->

The important part is the value of the url attribute: file://$USER_HOME$/fvm/versions/3.13.9/bin/cache/dart-sdk/lib/async.

Initially (so whatever Android Studio figured out itself) it points to $USER_HOME$. So, whenever you would switch the SDK via fvm use nothing in Android Studio will change. In the UI you only see the resolved base path. In my case this is /Users/manuelrauber/fvm/versions/3.13.9.

So far, this should be whatever you've observed as well.

But, let's make some "magic" happen:

In FVM, I did a little change to reactivate the flutter_sdk symlink:

 void _updateLocalSdkReference(Project project, CacheFlutterVersion version) {
-// Legacy link for fvm < 3.0.0
-  final legacyLink = join(
+  final currentSdkLink = join(
     project.localFvmPath,
     'flutter_sdk',
   );
 
-  // Clean up pre 3.0 links
-  if (legacyLink.link.existsSync()) {
-    legacyLink.link.deleteSync();
+  if (currentSdkLink.link.existsSync()) {
+    currentSdkLink.link.deleteSync();
   }

  // ...

   project.localVersionSymlinkPath.link.createLink(
     version.directory,
   );
+
+  currentSdkLink.link.createLink(
+    version.directory,
+  );

Not sure, if that will be enough at all, but I just wanted to have that symlink back.

Now, in Android Studio I use the "..." button, to select the newly created symlink (in my case that's /Users/manuelrauber/project/my-project/.fvm/flutter_sdk):

As you can see in the image, the symlink is resolved (what you have observed as well).

But here is the "magic": That is only visually in the settings dialog!

In Dart_SDK.xml it actually changed how that information where the SDK is located is being saved to:

<root url="file://$PROJECT_DIR$/.fvm/flutter_sdk/bin/cache/dart-sdk/lib/async" />

It now uses $PROJECT_DIR$ instead of $USER_HOME$.

Sweet!

If I now run fvm use 3.13.9 again, I can see that Android Studio starts to re-index due to the SDK being changed.

So, basically it works like already described on the docs if we can get the flutter_sdk symlink back.

---

I was also thinking about changing the paths saved in Dart_SDK.xml directly when the fvm use command is executed, but I think that could be a bit wonky whenever the Flutter Plugin will update and it may introduce potential bugs, because two tools manage the paths. With the flutter_sdk symlink solution it seems to be more solid.

[leoafarias]

@ManuelRauber looks good, could you make a PR with that change, so I can bring it over before releasing 3.0, also if its not too much to ask, I want to create a page about Android Studio integration, and maybe explain that behavior, so people are aware of these details.

[ManuelRauber]

@ManuelRauber looks good, could you make a PR with that change, so I can bring it over before releasing 1.0, also if its not too much to ask, I want to create a page about Android Studio integration, and maybe explain that behavior, so people are aware of these details.

@leoafarias yes, I can do a PR that includes:

• the SymLink
• Docs
• Maybe a little check in fvm doctor or so that simply outputs if PROJECT_DIR is found in idea settings