# Dart Code activates on pubspec.yaml and refuses untrusted workspaces > Dart Code is the VS Code extension that gives Dart and Flutter their language server, debugger and hot reload, published from the Dart-Code marketplace publisher. Its package metadata is explicit about workspace trust, telemetry and which files wake the extension up, which is more than most extension READMEs tell you. **Dart-Code/Dart-Code** — Dart and Flutter support for VS Code - Repository: https://github.com/Dart-Code/Dart-Code - Website: https://dartcode.org/ - Stars: 1,605 · Forks: 351 - Language: TypeScript - License: MIT - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/dart-code-dart-code ## Activation is a list of file globs, and that is a design statement The `activationEvents` array in `package.json` is the most informative thing in this repository, because it says exactly what wakes the extension. There are twenty-three entries, and they fall into four groups. The largest group is `workspaceContains` globs for the three project marker files: `pubspec.yaml`, `analysis_options.yaml` and `.dart_tool`, each repeated at one, two and three levels of directory depth so that monorepos activate as well as single projects. The next group is `workspaceContains` globs for `*.dart` files at the same three depths. The remaining entries are `workspaceContains` conditions for four create project markers, one explicit command, `onCommand:_dart.flutter.createSampleProject`, and four event subscriptions: `onTaskType:dart`, `onTaskType:flutter`, `onUri` and `onDebugDynamicConfigurations`. Read together, this says the extension is designed for a workspace that contains Dart projects rather than for a loose file you opened once. A folder with no `pubspec.yaml`, no analysis options, no `.dart_tool` and no `.dart` files will not start it, which is what keeps the startup cost off unrelated code bases in a monorepo. The `onTaskType` entries are subtler. They mean the extension activates when a task of type `dart` or `flutter` runs, which covers terminal driven workflows where you never open a Dart file at all. Two packaging settings reinforce the workspace-first view. `extensionKind` is `["workspace"]`, so the extension runs in the remote or container side when you are connected to one, which is the right choice for an extension that launches an SDK and a debugger. And the main entry point is `./out/dist/extension`, a webpack build, with `webpack.config.js`, `tsconfig.build.json` and a separate `tsconfig.json` at the root. ## What the feature list actually buys a Flutter developer The README's feature list is long, and most of it is language tooling that any Dart setup provides. The items that are specific to this extension are the Flutter execution features and the package management automation. On execution: edit and debug Flutter mobile apps and Dart command line apps, both launched with F5 or the Debug menu. Automatic hot reloads for Flutter are controlled by the `dart.flutterHotReloadOnSave` setting, and there is a documented workflow for quickly switching between devices for Flutter. On packages, which is where the extension does more than provide a language server: a Flutter Get Packages command, a Flutter Upgrade Packages command, a Pub Get Packages command, and a Pub Upgrade Packages command. More usefully, it gets packages automatically when `pubspec.yaml` is saved, controlled by `dart.runPubGetOnPubspecChanges`, and it prompts to get packages when they are out of date through `dart.promptToGetPackages`. Those two settings are the difference between an extension that is correct after a fresh clone and one that makes you run a command. On SDK discovery, it finds SDKs automatically from PATH, and it notifies you when a new stable Dart SDK release appears through `dart.checkForSDKUpdates`. For teams on pinned SDK versions that notification is noise you switch off; for individuals it is a useful nudge. On debugging, there are two settings that control scope: `dart.debugSdkLibraries` and `dart.debugExternalPackageLibraries`, giving you the choice between just my code and also SDK or external library code. That pair is the setting most teams change from the default, because stepping into a dependency is useful once and expensive thereafter. The rest is standard language service: syntax highlighting, code completion, snippets in a `snippets/` directory, realtime errors, warnings and TODOs, hover documentation, go to definition, find references, rename, organize imports, format document with support for `editor.formatOnSave` and `editor.formatOnType`, workspace and document symbol search, type hierarchy, sort members, refactorings and code fixes, and a Flutter Doctor command. ## Workspace trust is off, virtual workspaces are limited The `capabilities` block in `package.json` answers a question most extension READMEs leave open. `untrustedWorkspaces` is set to `supported: false`. In VS Code terms, the extension will not run in a workspace that has not been trusted. For a language extension that launches an SDK and attaches a debugger, that is the correct default: an extension that can start processes and evaluate code has no business running against files the user has not vouched for. The practical consequence is that opening an untrusted checkout of a Dart project will show Dart as unsupported until the workspace is trusted. `virtualWorkspaces` is `supported: "limited"`, with a description saying some functionality may be limited for remote files in virtual workspaces. The metadata does not specify which functionality is affected. The `engines` field requires VS Code `^1.101.0`, which is a floor rather than a recent version, so the extension runs on a wide range of editors but uses APIs that only exist from 1.101. The extension categories are Programming Languages, Snippets, Linters, Formatters, Debuggers and Testing, and the keywords list includes `fuchsia` as well as `dart` and `flutter`, which points at the Dart team's other platform target. The version in `package.json` is `3.146.0-dev`, against the published v3.144.0. The extension ships a development version ahead of the marketplace build, so the repository state is not what a user gets from installing. ## Telemetry is specific and switchable The Analytics section is short and worth reading before this extension goes into a company image. The extension reports extension load and analysis times, version numbers for the Dart and Flutter extensions and SDKs, the values of some settings such as the Flutter UI Guidelines setting and Format-on-Save, and the frequency of use of features like Hot Reload and Hot Restart. Reporting can be disabled through VS Code's standard Telemetry: Telemetry Level setting. The repository has a `telemetry.json` at the root, which is where the declaration lives, and a `codecov.yml` alongside a coverage badge in the README header pointing at codecov.io for this repository. One thing the extension does not send is any indication of what you wrote. That is a claim about what the README enumerates rather than an audit, so read `telemetry.json` if your review needs the schema rather than the summary. Installation is the ordinary route: from the Visual Studio Code Marketplace, or by searching within VS Code in the extension gallery. The publisher is `Dart-Code` and the display name in the marketplace is `Dart`, which is a detail worth knowing when you write internal provisioning scripts, since the repository name and the marketplace name differ. ## Conclusion Adopt Dart Code if you write Dart or Flutter in VS Code and want the analysis server, refactorings and device debugger rather than an editor with only syntax highlighting. Do not adopt it in an untrusted workspace, since the extension declares untrustedWorkspaces as unsupported, and check your organisation's telemetry policy before enabling it in a corporate image, since it reports load times, SDK versions and feature usage. Verify first that your VS Code is at least 1.101.0, that the Dart SDK is on PATH or discoverable, and which settings you want changed from their defaults before you hand the configuration to a team. ## FAQ ### How do I install Dart Code in VS Code? Install it from the Visual Studio Code Marketplace or search for it in VS Code's extension gallery. The package is published as Dart-Code and its display name in the marketplace is Dart, and package.json requires VS Code ^1.101.0. ### Why does the Dart extension not activate in my project? Activation includes workspaceContains globs for pubspec.yaml, analysis_options.yaml,.dart_tool and *.dart files, plus commands, dart and flutter task types, URIs and debug configurations. ### What analytics does Dart Code send? Extension load and analysis times, version numbers for the Dart and Flutter extensions and SDKs, the values of some settings such as the Flutter UI Guidelines setting and Format-on-Save, and the frequency of use of features like Hot Reload and Hot Restart. Reporting is controlled by VS Code's Telemetry: Telemetry Level setting. ### Does Dart Code support Flutter hot reload and device debugging? Yes. It edits and debugs Flutter mobile apps and Dart command line apps with F5, supports automatic hot reloads on save through the dart.flutterHotReloadOnSave setting, and documents quickly switching between Flutter devices. ### Can I use Dart Code in an untrusted VS Code workspace? No. package.json sets capabilities.untrustedWorkspaces to supported false. Virtual workspaces are marked limited, with some functionality potentially unavailable. ## Sources - [Dart-Code/Dart-Code on GitHub](https://github.com/Dart-Code/Dart-Code) - [License: MIT](https://github.com/Dart-Code/Dart-Code/blob/master/LICENSE) - [Project website](https://dartcode.org/) - [README](https://github.com/Dart-Code/Dart-Code/blob/master/README.md) - [Releases](https://github.com/Dart-Code/Dart-Code/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dart-code-dart-code