Selecting a language without the base leaves pnpm_env undefined

[catinspace-au]

Node moved into the core developer role, which is the right call -- semantic-release and hyperi-ci need it whatever language you work in. But the include is tagged ['developer', 'nodejs'], and nothing about selecting a LANGUAGE selects those tags. So a run that asks for languages without also asking for the base gets the consumer without the producer.

What that looks like:

• developer/tasks/nodejs.yml sets pnpm_env (and installs pnpm itself) near the end of the file.
• developer-node/tasks/nodejs.yml and developer-typescript/tasks/typescript.yml both do environment: "{{ pnpm_env }}".
• Skip the first and the other two die on Error processing keyword 'environment': 'pnpm_env' is undefined.

The meta dependency is fine -- developer-node declares developer and always has. It is the TAG selection that defeats it, so adding another dependency is not the fix.

Worth noting defining the var alone would not fix it either. If nodejs.yml did not run then pnpm is not installed, so pnpm install -g would just fail one step later with a nicer message.

We hit this on the desktop VM template build, which runs --soe --languages --tags infrastructure,rdp-server,vm,power-profile. It failed 280 tasks in. We have worked around it our side by naming nodejs in the tag list, so we are not blocked -- but ./install.sh --languages typescript on a plain workstation still breaks the same way, and that one is in the help text.

DONE WHEN a run that selects a language toolchain gets node and pnpm without having to know it must also ask for the base.

[catinspace-au]

The repro in the body does not hold any more, but there IS a bug here and it is bigger than the title.

--tags developer-typescript and --tags developer-languages both select the Node producer, so neither breaks. Only the raw, undocumented typescript tag does -- --list-tasks shows it picking "Install TypeScript and tsx/ts-node" and not the Node task.

The real cause is not the typescript wiring though. developer/tasks/main.yml included init.yml with tags: ['always'] and NO apply block. The include therefore ran, but the tasks inside it kept no tags of their own, so under ANY narrow --tags run every fact init.yml sets was silently skipped. pnpm_env was just the one that happened to blow up loudly.

Found it the hard way: moving pnpm_env into init.yml did not fix anything, and the check run still failed with 'pnpm_env' is undefined. Adding apply is what fixed it.

That also explains why nobody hit this more often -- actual_user and user_home survive because playbooks/main.yml pre_tasks set them again with tags: ['always'].

--tags typescript --check now completes with failed=0.

Fix in #70.

[catinspace-au]

Landed in 06035f1 (#70). The real cause was init.yml being included without an apply block, so its facts vanished under any narrow --tags run. --tags typescript --check now completes with failed=0.