Task packaging fails to correctly resolve `pnpm`'s symlinked `node_modules`
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 58/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- node.js, typescript
- Domain
- build-system, cli
Research direction
Start at the task upload packaging path that calls archiver's archive.directory(...), then inspect how links are represented in the generated zip. Verify completion by packaging a pnpm-installed task and confirming the extracted node_modules contains usable file contents rather than symlink or hardlink metadata.
Written by the indexing model from the issue text.
Description
Description
When developing Azure DevOps Custom Tasks and using pnpm as the package manager, the task upload command fails to correctly bundle the node_modules directory.
pnpm relies heavily on symbolic links to create its strict node_modules structure, and hardlinks to the global store for the actual files. The current implementation uses archiver (specifically archive.directory(...)) without dereferencing/following these links.
Server-Side Verification
I have manually verified this behavior directly on the Azure DevOps Agent server. Upon inspecting the extracted task directory on the server, the node_modules folder structure is incomplete and broken. The hardlinks and symlinks were stored as metadata or empty placeholders rather than being dereferenced into physical files during the zip process. The agent cannot resolve the dependencies, rendering the task completely unusable.
Expected Behavior
The packaging tool should fully dereference (follow) symlinks and hardlinks during the zipping process, copying the actual physical file contents into the archive. This ensures the .zip contains a self-contained, fully resolved node_modules tree that works seamlessly on the agent, regardless of the local package manager used (npm, yarn, or pnpm).
- Dominant language
- TypeScript
- Stars
- 386
- Forks
- 142
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 7
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/tfs-cli
-
Area: tfx-cli DevOps enhancement
Difficulty 1/5 Under an hour Newbie friendliness 68/100
-
Area: tfx-cli triage
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
Area: tfx-cli triage
Difficulty 3/5 1-2 days Newbie friendliness 45/100
-
Area: tfx-cli triage
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
Area: tfx-cli triage
Difficulty 4/5 3-5 days Newbie friendliness 25/100
All issues in microsoft/tfs-cli
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug clawsweeper:linked-pr-open clawsweeper:needs-live-repro clawsweeper:no-new-fix-pr impact:message-loss issue-rating: 🐚 platinum hermit P2 regression
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
fullcalendar/fullcalendar#8106 ·