script.js<\/code>\u00a0, \u00a0task.json<\/code>\u00a0, and \u00a0icon.png<\/code>\u00a0). The change took about 20 lines of build tooling. We measured the payoff across our production pipelines:<\/p>\n\n- Per-task download + extract on the agent: ~4.5 s to ~0.25 s (about 17x faster)<\/li>\n
- Downloads taking longer than 10 seconds: down ~98%<\/li>\n<\/ul>\n
Spending less time downloading and extracting tasks means we can make more efficient use of our build infrastructure. If you publish a node-based Azure DevOps task extension that ships a large node_modules<\/code> folder or thousands of small files, you can almost certainly benefit from this same change!<\/p>\nWhy task package size matters more than you think<\/h2>\n
Every time a pipeline job runs your task, the agent does the following during \u2018Initialize job\u2019, before your task code ever executes:<\/p>\n
\n- Downloads the task\u2019s content zip<\/li>\n
- Extracts it to disk.<\/li>\n<\/ol>\n
This happens on every job, on every agent, for every task in the job. On ephemeral hosted agents (which start from a clean VM), there is no cache to save you from this startup cost.<\/p>\n
Our task had grown the way node-based tasks tend to: the compiled TypeScript plus a full\u00a0node_modules<\/code>\u00a0tree that our build copied into each task folder. The result, quoting our own build script:<\/p>\n\/\/ package huge (tens of MB and thousands of files per task).<\/code><\/p>\nThousands of small files is the problem here. Task extensions are packaged in a vsix file which is really just a zip file that follows a specific packaging convention. Zipping and unzipping a package with thousands of files is costly. In this case it\u2019s also completely unnecessary.<\/p>\n
Bundling and pruning aren\u2019t just for the browser<\/h2>\n
Bundlers and tree-shaking carry a reputation as front-end tools. We reach for them to ship less JavaScript to a browser over a slow network, and it\u2019s easy to assume that a server-side or CLI-style program, where \u201cit all runs on one machine anyway,\u201d has nothing to gain.<\/p>\n
A pipeline task is a distributable artifact that each build agent downloads and unpacks from scratch on every run, often thousands of times a day across many agents. That is the problem bundling helps to solve. Front-end developers are familiar with optimizing assets to minimize the cost of transferring and processing files. The same cost applies here; the difference is the build agents pay the cost instead of browsers.<\/p>\n
The same logic applies to anything you distribute and load repeatedly: pipeline tasks, npm-published CLIs, serverless function packages, even container image layers. If your artifact drags an entire node_modules<\/code> tree along for the ride, tree-shaking away the code you never call and collapsing what\u2019s left into one file pays off wherever it lands. Treat your task like something you ship, not like a folder you develop in.<\/p>\nThe fix: bundle everything into one file<\/h2>\n
We added a single esbuild build step that bundles each task\u2019s entry point, together with the shared Common\u00a0code and all of its npm dependencies, into one bundled, tree-shaken script.js<\/code> per task. The task\u2019s VSIX then only needs to ship, per task:<\/p>\nTasks\/{taskname}\/\n script.js (the entire bundled task)\n task.json (the task manifest)\n icon.png<\/pre>\nYou no longer ship hundreds of transitive dependency files in multiple node_modules<\/code> folders. You simply point task.json<\/code>\u2018s execution target field at script.js<\/code>, and that\u2019s it.<\/p>\n{\n \/\/...\n \"execution\": {\n \"Node20_1\": {\n \"target\": \"script.js\",\n \"workingDirectory\": \"$(currentDirectory)\"\n }\n }\n}\n<\/pre>\nThe essence of the build script:<\/p>\n
import * as esbuild from \"esbuild\";\n\nawait esbuild.build({\n entryPoints: [\"Tasks\/MyTask\/index.ts\"], \/\/ one per task\n outfile: \"Tasks\/MyTask\/script.js\",\n bundle: true,\n treeShaking: true,\n platform: \"node\",\n target: \"node20\", \/\/ Target the lowest Node handler your task.json declares, or emit one bundle per handler\n format: \"cjs\"\n});<\/pre>\nTwo gotchas<\/h2>\n
We hit two subtle issues that other publishers might hit too:<\/p>\n
\n- Deduplicate stateful shared modules. If you install the same package (for example\u00a0azure-pipelines-task-lib) in both a shared\u00a0
Common\/node_modules<\/code>\u00a0and each task\u2019s own\u00a0node_modules<\/code>, esbuild can bundle two separate copies. For libraries that hold module-level state, that state splits across the copies and silently disappears (for example with azure-pipelines-task-lib<\/code>, the internal\u00a0_vault<\/code> that holds secrets). We wrote a small esbuild resolver plugin that forces bare-specifier imports to resolve to a single, canonical node_modules<\/code>. <\/li>\n- Fix sibling-asset paths if your extension contains multiple tasks and they share common code. For example:<\/li>\n<\/ol>\n
Common\n moduleA.js\n moduleB.js\nTask1\n script.js\n task.json\n distribution.json (custom file needed by the task)\nTask2\n script.js\n task.json\nTask3\n<\/pre>\nBundling collapses the Tasks\/{taskname}\/Common\/<\/code>\u00a0subfolder, so the emitted script.js<\/code> now lives one level up from where the source did. Update any runtime reads of sibling files (\u00a0task.json\u00a0, \u00a0distribution.json\u00a0) that use \u00a0__dirname<\/code>\u00a0 to drop the now-incorrect \u00a0..\/<\/code>\u00a0 prefix.<\/p>\nThese changes took a couple iterations to fix, but knowing about them up front might save you a confusing debugging session.<\/p>\n
How we measured the impact<\/h2>\n\n- Task file transfer time measures how long the Azure DevOps service spends streaming each task\u2019s zip to the agent. Across all downloads, the average dropped from ~1.35 s to ~0.23 s, and downloads taking more than 10 seconds (slow network) fell by ~98%. Here we already saw a big improvement.<\/li>\n
- Agent-side download and package extraction time. This is the number that matters to customers because it means more efficient use of build agent compute.<\/li>\n<\/ol>\n
![\"\ud83d\udd3b\"](\"https:\/\/s.w.org\/images\/core\/emoji\/17.0.2\/72x72\/1f53b.png\")
\u221294%<\/strong>\n <\/td>\n<\/tr>\n