Rather than hard-coding various npm scripts in the actual package.json, farm them out to a lib and some simple sub-commands scripts.
[updated] To use it, do one of
npm run klotho build: Does all the npm, klotho, and pulumi build steps (including npm install if needed, and in the compiled dir)
npm run pulumi ...: forwards to pulumi, with the appropriate stack name and cwd
this also exports PULUMI_CONFIG_PASSPHRASE=''if you don't have either PULUMI_CONFIG_PASSPHRASE or PULUMI_CONFIG_PASSPHRASE_FILE set; Klotho's default generated stack requires an empty password
Note that this sets up a non-standard directory structure for klotho output, but only if you use an app name other than the default (by setting an env var). Instead of compiled, it's compiled-klotho/$app_name. This is specifically to keep prod and dev compilations/deployments separate, which is an important use case for me. But I'm flexible on it, and especially on the specific dir structure.
Rather than hard-coding various npm scripts in the actual package.json, farm them out to a lib and some simple sub-commands scripts.
[updated] To use it, do one of
npm run klotho build
: Does all the npm, klotho, and pulumi build steps (includingnpm install
if needed, and in the compiled dir)npm run pulumi ...
: forwards topulumi
, with the appropriate stack name and cwdPULUMI_CONFIG_PASSPHRASE=''
if you don't have eitherPULUMI_CONFIG_PASSPHRASE
orPULUMI_CONFIG_PASSPHRASE_FILE
set; Klotho's default generated stack requires an empty passwordNote that this sets up a non-standard directory structure for klotho output, but only if you use an app name other than the default (by setting an env var). Instead of
compiled
, it'scompiled-klotho/$app_name
. This is specifically to keep prod and dev compilations/deployments separate, which is an important use case for me. But I'm flexible on it, and especially on the specific dir structure.Updated documentation: CloudCompilers/docs#93