You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have all 4 Flutter SDK channels installed. The stable channel is on my PATH, and I swap to the others via the status bar in VSCode.
If I have a project open using the dev channel, and I use the Flutter: New Project command, the new project appears to be created using the SDK on my path (stable) instead of the active SDK (dev). To clarify: I'm running Flutter: New Project in an open project displaying the dev SDK in the status bar.
The resulting project opens with the stable SDK selected in the status bar, and does not show web as a target platform, which makes me believe it was built using the stable SDK. I have to manually use the dev SDK to run flutter create . (because it isn't available via VSCode)
Thanks - I realised what's happening now. When we create a new project, there are multiple steps:
We write a "trigger file" into the folder where the project will be created
We spawn open that folder in VS Code
The extension spots the trigger file as it activates, and runs the create code
The reason for doing it this way, is that you get to see the creation process happen in the window where you'll work on the project (we used to run create and all the output would be visible in the previous window, then we spawn a new one opening the project).
Opening a new window before running create means we no longer see the settings from the previous workspace, and instead will see global settings (eg. no overridden SDK path).
I think we should store the SDK path inside the trigger file if it's been overridden, then set it for that workspace during the creation process.
I think we should store the SDK path inside the trigger file if it's been overridden, then set it for that workspace during the creation process.
This felt a bit clunky because we can for the SDK before processing trigger files. So now I just write the settings file directly (it's a clean directory, so we don't have to worry about existing settings). It's only written if your current workspace has an overridden path (eg. if you select auto-detect and then run it, there will be no .vscode folder created).
Activity
DanTup commentedon Sep 30, 2019
Thanks - I realised what's happening now. When we create a new project, there are multiple steps:
The reason for doing it this way, is that you get to see the creation process happen in the window where you'll work on the project (we used to run create and all the output would be visible in the previous window, then we spawn a new one opening the project).
Opening a new window before running
createmeans we no longer see the settings from the previous workspace, and instead will see global settings (eg. no overridden SDK path).I think we should store the SDK path inside the trigger file if it's been overridden, then set it for that workspace during the creation process.
Write SDK path into settings for newly created projects if overriden …
DanTup commentedon Oct 8, 2019
This felt a bit clunky because we can for the SDK before processing trigger files. So now I just write the settings file directly (it's a clean directory, so we don't have to worry about existing settings). It's only written if your current workspace has an overridden path (eg. if you select auto-detect and then run it, there will be no
.vscodefolder created).Write SDK path into settings for newly created projects if overriden …