feat(glob): split vite_glob into env/path modules; env globs support negation#425
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
9c67598 to
6d7dfd5
Compare
df080de to
79a5945
Compare
…negation
`vite_glob` wrapped `wax`, a filesystem path-glob engine, but most callers
used it to match environment-variable *names* — flat strings, not paths —
by pushing `&str` through `is_match(impl AsRef<Path>)`. That is semantically
muddy, and `wax` exposes no option to disable its path semantics.
Reorganize the crate into two modules, each with its own matchers and error
type:
- `vite_glob::env` — `EnvGlob` (one literal pattern) and `EnvGlobSet` (a set,
backed by `globset`) with `literal_separator(false)` and
`case_insensitive(cfg!(windows))`, so `*`/`?`/`[...]`/`{a,b}` are pure
flat-string wildcards with the platform's env case rules. `EnvGlobSet`
supports **negation**: a `!`-prefixed pattern excludes, and a name matches
when it matches an include and no exclude (e.g. `["VITE_*", "!VITE_SECRET"]`).
Errors: `EnvGlobError`.
- `vite_glob::path` — `PathGlobSet` (the former `GlobPatternSet`, renamed),
still `wax`-backed with unchanged gitignore (first/last-match-wins)
semantics. Errors: `PathGlobError`.
This mirrors how Turborepo splits env (regex) from path (wax) matching, and how
Turbo treats `!` in env wildcards. Non-negated env results are unchanged —
globset matches the same `*`/`?`/`[...]`/`{}` syntax wax did for separator-free
names, including SENSITIVE_PATTERNS and the Unix/Windows case split (covered by
existing envs.rs tests).
Migrate the pre-existing callers: `envs.rs` uses `EnvGlobSet` for its
multi-pattern env matching — so `env: ["VITE_*", "!VITE_SECRET"]` in a task
config now excludes `VITE_SECRET` (previously `!` patterns were dropped with a
warning) — and `vite_workspace` switches to `PathGlobSet` / `PathGlobError`.
The runner-aware env-matching sites consume the single-pattern `EnvGlob` in the
stacked PR.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
vite-task/crates/vite_task_plan/src/envs.rs
Lines 92 to 96 in 2c3f080
When env and untrackedEnv both contain patterns for the same variable, this merges both lists into one negating matcher before fingerprinting. A negation intended only to subtract from an untracked wildcard, e.g. untrackedEnv: ["CI_*", "!CI_SECRET"] with env: ["CI_SECRET"], removes CI_SECRET from all_envs here, so the later fingerprint pass never sees it and the task does not receive it at all. The two config fields have different meanings, so their include/exclude sets need to be resolved separately and then unioned.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

vite_globwrapswax, a filesystem path-glob engine — but most callers use it to match environment-variable names, which are flat strings, not paths. They push&strthroughis_match(impl AsRef<Path>), which is semantically muddy, andwaxexposes no option to disable its path semantics.This reorganizes the crate into two modules, each with its own matchers and separate error type, and adds negation to env-name matching:
vite_glob::env—EnvGlob(one literal pattern) andEnvGlobSet(a set), backed byglobsetwithliteral_separator(false)andcase_insensitive(cfg!(windows)), so*/?/[...]/{a,b}are pure flat-string wildcards with the platform's env case rules (sensitive on Unix, insensitive on Windows).EnvGlobSetsupports negation: a!-prefixed pattern excludes, and a name matches when it matches an include and no exclude. Errors:EnvGlobError.vite_glob::path—PathGlobSet(the formerGlobPatternSet, renamed); stillwax-backed with unchanged gitignore (first/last-match-wins) path semantics. Errors:PathGlobError.This mirrors how Turborepo splits env (
regex) from path (wax) matching, and how Turbo treats!in env wildcards. Non-negated env results are unchanged — globset matches the same*/?/[...]/{}syntax wax did for separator-free names, includingSENSITIVE_PATTERNSand the Unix/Windows case split (covered by existingenvs.rstests).User-facing change
env: ["VITE_*", "!VITE_SECRET"]in a task config now fingerprints everyVITE_*env exceptVITE_SECRET. Previously!-prefixed env patterns were dropped with a warning (no negation). Single-patternEnvGlob(used by the runner'sgetEnvs) stays literal —!has no special meaning there.Migration
Pre-existing callers:
envs.rsusesEnvGlobSetfor its multi-pattern env matching;vite_workspaceswitches toPathGlobSet/PathGlobError. The runner-aware env-matching sites consume the single-patternEnvGlobin the stacked PR #410.globsetis a new dependency (BurntSushi / ripgrep); its transitive deps (aho-corasick,regex) were already in the tree.