FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Add validation that the extension name matches the package name by johnpryan · Pull Request #9965 · flutter/devtools · GitHub

Add validation that the extension name matches the package name - #9965

Open
johnpryan wants to merge 2 commits into
flutter:masterfrom
johnpryan:ensure-extension-names
Open

Add validation that the extension name matches the package name#9965
johnpryan wants to merge 2 commits into
flutter:masterfrom
johnpryan:ensure-extension-names

Conversation

Copy link
Copy Markdown
Contributor

This ensures that packages can't provide extensions for package with a different name.

To test this behavior, create a new package under packages/devtools_extensions/example/test_validation_pkg:

devtools/config.yaml:

name: provider
issueTracker: https://github.com/flutter/devtools/issues
version: 1.0.0
materialIconCodePoint: "0xe50a"
requiresConnection: false

pubspec.yaml:

name: bad_pkg
description: A test package for manually validating DevTools extension configs.
version: 1.0.0

environment:
  sdk: ^3.11.0

Run the validator:

dart run devtools_extensions validate -p example/test_validation_pkg
Validation error: The "name" field in config.yaml (TEST_VALIDATION_PKG) does not match the package name in pubspec.yaml (test_validation_pkg).

Ensure that an extension's name in config.yaml matches the package name
in pubspec.yaml
johnpryan requested review from a team and bkonyi as code owners August 18, 2026 18:46

gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Code Review

This pull request introduces validation during DevTools extension discovery and validation to ensure that an extension's declared name in config.yaml matches its containing package name. If there is a mismatch, the extension is ignored (with a warning) or validation fails. This is implemented across devtools_shared and devtools_extensions, with corresponding tests added.

Feedback on the changes highlights two potential runtime issues:

  1. In extension_manager.dart, if the name field in config.yaml is missing or not a string, the extension will be silently ignored with a mismatch warning instead of throwing a more descriptive parsing error. It is suggested to only perform the mismatch check if extensionName is a String.
  2. In _validate.dart, casting pubspecYaml['name'] and configYaml['name'] directly using as String? can cause a runtime TypeError if the fields are parsed as non-string types. Safe type checking should be used instead.

kenzieschmoll left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

The actually breaks an intentional feature of DevTools extensions that allows you to develop your extension in a different package than the one where you ship it. See https://github.com/rrousselGit/provider/tree/master/packages for an example. This is necessary because many package authors want to decouple their Flutter Web project (DevTools extension) from their package that users import as a direct dependency. Developing the devtools extension in another package allows the Flutter web code and deps to be kept separate from the package users depend on.

johnpryan commented Aug 18, 2026
edited
Loading

Copy link
Copy Markdown
Contributor Author

I didn't realize that was the intended behavior. I'm not sure how exactly to proceed. Here here are some alternatives we could consider:

  1. Allow the devtools name to match the package name foo OR foo_devtools_extension. That way a package likebad_pkg can't claim to be foo. This isn't great because this would still mean that someone could publish foo_devtools_extension, even if they didn't own foo.
  2. Improve the deduplication logic, so that if package:foo and package:bad_package both claim to provide the foo devtools extension in the same workspace, we choose to use the correct version (although I'm not exactly sure how to determine this if there's no strong association between the extension package and the parent package)

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
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

Successfully merging this pull request may close these issues.

2 participants


Back | FazBrowse Home | New Git URL