Feature Request: Support negated glob patterns in pub workspaces

[GiancarloCante]

Currently, pub workspaces support inclusive glob patterns only. Workspace resolution effectively computes the union of all matched paths.

For example:

workspace:
  # specify a package in a direct subdir of the root
  - 'my-app'
  # all packages in direct subdirs of packages/
  - 'packages/*'
  # all packages in subdirs of components/
  - 'components/**'
  # attempt to exclude packages inside test directories
  - '!**/test/**'   # ❌ Not supported

Negated patterns (!pattern) are not currently supported and are treated as literal glob strings rather than exclusions.

---

Proposal

Add support for negated glob patterns (!pattern) in the workspace: section of pubspec.yaml so workspace membership can explicitly exclude specific paths.

Proposed Resolution Semantics

Patterns would be evaluated in order:

1. Start with an empty workspace set.

2. For each pattern:

   • Positive pattern → add matching directories.
   • Negated pattern (!pattern) → remove matching directories from the current set.

Example:

workspace:
  - 'packages/*'
  - '!packages/experimental'

This would include all packages under packages/ except packages/experimental.

Order would matter:

workspace:
  - 'foo'
  - '!foo'
  - 'foo'

Final result: foo is included.

Negated patterns would only remove currently included workspace members; later positive patterns could add them again.

---

Reasoning

• Improves monorepo ergonomics
• Allows excluding test fixtures, experimental folders, or generated code
• Avoids forcing directory restructuring solely to satisfy workspace constraints
• Aligns with behavior in other workspace-based package managers

[crackedhandle]

I’ve been reading through this proposal and I’d really like to try working on it if that’s okay.

From what I understand, the main change would be shifting workspace resolution from the current “union of all matches” approach to an ordered evaluation model — starting with an empty set, adding matches for positive patterns, and removing matches for negated (!pattern) ones as we iterate in order. Later positive patterns should still be able to re-include previously excluded paths.

Does that align with how you’d expect this to be implemented? I’d love to get your thoughts before I go deeper into the code. Also, if there’s a particular area in the workspace resolution logic you recommend starting with, that would be really helpful.

Thanks