Summary
projen 0.101.0 introduced a cross-platform shell (#4770, commit 8a24b61) that does not implement $(...) command substitution. Any task exec step that uses $(...) — either in argument position or in a variable assignment — throws Not implemented: command and aborts.
This is a regression — the 0.101.0 release notes explicitly call out $(...) as a feature that flows through the new shell:
Tasks, conditions and dynamic ($(...)) environment variables now run through projen's built-in cross-platform shell on all platforms.
…so the intent was clearly to support $(...), not to break it.
Reproduction
Minimal repro — one task file, one line:
mkdir repro && cd repro
cat > package.json <<'PKG'
{ "name": "repro", "version": "0.0.1", "private": true, "devDependencies": { "projen": "0.101.1" } }
PKG
mkdir .projen
cat > .projen/tasks.json <<'TASKS'
{ "tasks": { "t": { "name": "t", "steps": [ { "exec": "X=$(echo hi); echo $X" } ] } } }
TASKS
npm install --silent
npx projen tExpected (works in 0.100.7):
👾 t | X=$(echo hi); echo $X
hi
Actual (in 0.101.0 and 0.101.1):
👾 t | X=$(echo hi); echo $X
👾 Not implemented: command
Affected patterns (all fail on 0.101.x)
| Pattern |
Note |
X=$(echo hi) |
Command substitution in assignment |
echo $(echo wrapped) |
Command substitution in argument position |
X=$(echo hi); echo $X |
Combined assignment + use |
For comparison, these work fine on both 0.100.7 and 0.101.x:
echo a; echo b (sequential ;)X=hi; echo $X (bare assignment + use)echo $X (variable expansion alone)
So the issue is specifically $(...) — every other primitive in this set works.
Impact
We hit this on a CodeArtifact authentication task that's a very common projen-ecosystem pattern:
npm config set @scope:registry https://...;
CODEARTIFACT_AUTH_TOKEN=$(aws codeartifact get-authorization-token --domain ... --query authorizationToken --output text);
npm config set //...:_authToken=$CODEARTIFACT_AUTH_TOKEN
The pattern of "shell out to a CLI, capture the output into an env var, use the env var on a subsequent line" is extremely common. We have 4 production repos that hit this within hours of 0.101.0 being released; pinning to ~0.100 as a workaround.
Environment
- projen 0.101.1 (also reproed on 0.101.0)
- Node 22, macOS, Linux (GitHub Actions runners)
- node-package.js / standard NodeProject task layout
Suggested triage
Either the cross-platform shell needs $(...) support implemented, or it needs to fall back to the system shell for tasks containing $(...). Happy to test a patch.
Thanks for the project!
Summary
projen
0.101.0introduced a cross-platform shell (#4770, commit 8a24b61) that does not implement$(...)command substitution. Any taskexecstep that uses$(...)— either in argument position or in a variable assignment — throwsNot implemented: commandand aborts.This is a regression — the 0.101.0 release notes explicitly call out
$(...)as a feature that flows through the new shell:…so the intent was clearly to support
$(...), not to break it.Reproduction
Minimal repro — one task file, one line:
Expected (works in 0.100.7):
Actual (in 0.101.0 and 0.101.1):
Affected patterns (all fail on 0.101.x)
X=$(echo hi)echo $(echo wrapped)X=$(echo hi); echo $XFor comparison, these work fine on both 0.100.7 and 0.101.x:
echo a; echo b(sequential;)X=hi; echo $X(bare assignment + use)echo $X(variable expansion alone)So the issue is specifically
$(...)— every other primitive in this set works.Impact
We hit this on a CodeArtifact authentication task that's a very common projen-ecosystem pattern:
The pattern of "shell out to a CLI, capture the output into an env var, use the env var on a subsequent line" is extremely common. We have 4 production repos that hit this within hours of 0.101.0 being released; pinning to
~0.100as a workaround.Environment
Suggested triage
Either the cross-platform shell needs
$(...)support implemented, or it needs to fall back to the system shell for tasks containing$(...). Happy to test a patch.Thanks for the project!