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
{{ message }}
Repository navigation
Cannot run CLI script located in another package from a Flutter project's launch configuration since version 3.78.0 #4867
Since version 3.78.0 (commit) it is not possible anymore to run dart scripts from another package because the path has to start with bin/
We have a monorepo setup and one of the packages contains multiple cli scripts (for syncing the styleguide, syncing translations, exporting translations, ...) The way we do that is running the cli script but the cwd is actually the other package. Maybe a better approach would be to make it possible to debug cli scripts defined by the package, so for example dart pub run tools:toolX.
To Reproduce:
I created a demo project https://github.com/krispypen/dart_extension_bin_issue
if you open the workspace file in vscode and then try to run "Run toolX" it will not run because it is not recognized as a dart script. On version 3.76.1 and lower it works.
Expected behavior:
until version 3.76.1 it was possible to run dart cli scripts where the path contains bin
Screenshots:
##Version info:
Operating System and version: MacOS Sonoma
VS Code version: 1.84.2
Dart extension version: 3.78.0
Dart/Flutter SDK version: 3.13.6
Target device (if the issue relates to Flutter debugging): running dart script so no device
I need to convince myself whether this is a bug or desired functionality (we try to infer a lot of things when starting the debugger, and some of them are circular - like the script being run can influence the cwd and the cwd can influence which scripts we try to run). This does work:
"program": "bin/toolX.dart",
"cwd": "../tools",
Because it tells us to treat ../tools as the project root, so we then realise the path starts with bin.
However, I'm not sure this is perfect, because if you had a tool where you need the cwd to be another folder (for example where it's supposed to operate), then you wouldn't be able to do this.
I'll think a bit more about this and see if we can solve both this and the original issue together.
changed the title [-]Cannot run CLI script located on another package since version 3.78.0[/-][+]Cannot run CLI script located in another package from a Flutter project's launch configuration since version 3.78.0[/+]on Dec 4, 2023
However, I'm not sure this is perfect, because if you had a tool where you need the cwd to be another folder (for example where it's supposed to operate), then you wouldn't be able to do this.
Activity
Use top level folder name instead of finding bin/tool/etc. anywhere i…
DanTup commentedon Dec 4, 2023
Thank you for providing the simple repro!
I need to convince myself whether this is a bug or desired functionality (we try to infer a lot of things when starting the debugger, and some of them are circular - like the script being run can influence the cwd and the cwd can influence which scripts we try to run). This does work:
Because it tells us to treat
../toolsas the project root, so we then realise the path starts withbin.However, I'm not sure this is perfect, because if you had a tool where you need the cwd to be another folder (for example where it's supposed to operate), then you wouldn't be able to do this.
I'll think a bit more about this and see if we can solve both this and the original issue together.
[-]Cannot run CLI script located on another package since version 3.78.0[/-][+]Cannot run CLI script located in another package from a Flutter project's launch configuration since version 3.78.0[/+]DanTup commentedon Dec 4, 2023
btw - I'm curious why you have this in the launch.json of the Flutter app, and not in the CLI project itself (or in the
code-workspace)?DanTup commentedon Dec 13, 2023
This exact situation came up at #4894 (comment) from @akemimadoka, so it definitely needs a solution.
Refactor debugger type tests
DanTup commentedon Dec 14, 2023
@akemimadoka - could you try switching to the pre-release extension (v3.79.20231214 or newer) and test that my fix covers the setup you have?
Thanks!
krispypen commentedon Dec 14, 2023
My use-case works again with the pre-release version v3.79.20231214! 🎉 👍
akemimadoka commentedon Dec 15, 2023
It works like a charm! 🎉
Detect correct project types when running scripts outside of the defi…