chore(pnpm): remove tasks/e2e workspace#16881
Conversation
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
There was a problem hiding this comment.
Pull request overview
This PR consolidates the tasks/e2e workspace into the main monorepo workspace, removing the separate pnpm workspace configuration that was causing packages to be downloaded from npm on every CI run.
Key Changes:
- Removed separate workspace configuration (
tasks/e2e/pnpm-workspace.yaml) and lockfile (tasks/e2e/pnpm-lock.yaml) - Added
tasks/e2eand its subdirectories to the root workspace configuration - Simplified CI workflow by removing redundant
pnpm installcommand - Updated Renovate to ignore the
tasks/e2edirectory
Reviewed changes
Copilot reviewed 4 out of 6 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| tasks/e2e/pnpm-workspace.yaml | Deleted separate workspace config (no longer needed) |
| tasks/e2e/pnpm-lock.yaml | Deleted 3888-line lockfile (dependencies now managed at root level) |
| pnpm-workspace.yaml | Added tasks/e2e and tasks/e2e/tests to main workspace packages |
| .github/workflows/ci.yml | Simplified e2e test execution by removing redundant install step |
| .github/renovate.json | Added tasks/e2e to ignore paths to prevent automated updates |
Files not reviewed (1)
- pnpm-lock.yaml: Language not supported
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
tasks/e2eis now ignored by Renovate, which will likely prevent dependency/security updates for a workspace that still runs in CI.- CI’s e2e step now assumes dependencies are already installed from the root workspace; that coupling is fine if guaranteed, but fragile if the workflow changes.
- Listing both
tasks/e2eandtasks/e2e/testsas workspace packages is likely incorrect unlesstests/is a real standalone package; it can lead to confusing pnpm behavior and should be simplified.
Additional notes (1)
- Readability |
.github/workflows/ci.yml:196-203
The e2e job no longer runspnpm install --frozen-lockfileinsidetasks/e2e. This is probably intended after consolidating lockfiles, but it does introduce a subtle coupling: the step now assumes the root workspace install has already happened in this job and that the workspace install includestasks/e2edependencies.
If the job matrix or filter ever skips the root install step (or if tasks/e2e isn’t included in the installed subset), e2e can fail with missing deps. Also, you lose a local “lockfile is honored” assertion for the e2e workspace (though the root lockfile still applies).
Summary of changes
Summary
This change removes the standalone tasks/e2e pnpm workspace and folds it back into the root workspace/lockfile.
Key updates
-
Workspace layout
- Added
tasks/e2eandtasks/e2e/teststo the rootpnpm-workspace.yaml. - Deleted nested workspace files:
tasks/e2e/pnpm-lock.yamltasks/e2e/pnpm-workspace.yaml
- Added
-
CI workflow
- Simplified the e2e step to run
pnpm run testintasks/e2ewithout an extrapnpm install.
- Simplified the e2e step to run
-
Renovate config
- Updated
ignorePathsto includetasks/e2e.
- Updated
-
Lockfile consolidation
- Root
pnpm-lock.yamlnow includes animporters.tasks/e2esection and a large set of dependencies that previously lived intasks/e2e/pnpm-lock.yaml.
- Root
Merge activity
|
8c08383 to
041e2c7
Compare
f0f9fb2 to
8e48fbb
Compare
|
I give up. |
bbb3642 to
f69d4fa
Compare
f69d4fa to
dee1614
Compare
I thought making it a separate would be easier to manage, but it's actually not. Previous setup was also downloading packages from npm on every CI run.
dee1614 to
1d680de
Compare
I thought making it a separate would be easier to manage, but it's actually not. Previous setup was also downloading packages from npm on every CI run.

I thought making it a separate would be easier to manage,
but it's actually not.
Previous setup was also downloading packages from npm on every CI run.