apify create reports Success without validating the scaffold can run

[l2ysho]

Summary

apify create finishes with

Success: ✅ Actor 'my-actor' created successfully!

Next steps:

cd "my-actor"
apify run

without checking that either of those next steps will actually work. Two concrete ways the scaffold can be born broken while still reporting success.

Version: apify-cli/1.10.0 (d227b1f), darwin-arm64.

1. No node-version check against the template's engines.node

project_cheerio_crawler_ts declares:

"engines": { "node": ">=22" }

and builds on apify/actor-node:24.

My shell's default node was v20.20.2 (nvm, with the CLI itself installed under a different node version — an easy state to end up in). apify create installed dependencies and printed Success. The failure surfaces later at apify run, detached from the cause.

The CLI has both numbers at create time: the running node version and the template's engines.node. Comparing them is cheap.

Suggested: warn (not fail) when the running node does not satisfy the template's engines.node, and name the version the template expects.

⚠ This template requires Node >=22; you are running v20.20.2.
  `apify run` will likely fail. Switch with `nvm use 24`.

Writing an .nvmrc alongside the scaffold would also be a reasonable touch.

2. npm warn allow-scripts passes through uninterpreted

With npm's script-approval gate enabled, create's install ends with:

npm warn allow-scripts 2 packages have install scripts not yet covered by allowScripts:
npm warn allow-scripts   unrs-resolver@1.12.2 (postinstall: node postinstall.js)
npm warn allow-scripts   esbuild@0.28.2 (postinstall: node install.js)
npm warn allow-scripts
npm warn allow-scripts Run `npm approve-scripts --allow-scripts-pending` to review, or `npm approve-scripts <pkg>` to allow.

then Success three lines later.

esbuild is what vitest needs, so npm test — part of the validation gate this template ships a CI workflow for — can be broken from the first commit. The warning is npm's, but the CLI is the one declaring the scaffold ready.

Suggested: detect the unapproved-scripts warning in the install output and restate it in the CLI's own voice, or at minimum do not print Success without qualification when it appears.

Why together

Same shape: the CLI declares the project ready without verifying the project is ready. A cheap post-create sanity check — node satisfies engines, install completed without blocking warnings — would catch both, and would catch the next one too.

Related: #1424, #1425.

[l2ysho]

Reproduced both symptoms end-to-end since filing, plus a third that is more clear-cut than either. All three come from the same place: apify create declares the scaffold ready without checking it is.

The allow-scripts symptom has a deeper cause than I described

I originally framed this as npm's script-approval warning being passed through uninterpreted. Approving the scripts did not fix it:

$ npm approve-scripts esbuild unrs-resolver
Approved esbuild: added esbuild@0.28.2
Approved unrs-resolver: added unrs-resolver@1.12.2

$ npm test
Cannot find module './rolldown-binding.wasi.cjs'
Require stack:
- node_modules/rolldown/dist/shared/binding-DH95uVkp.mjs

The real cause is skipOptionalDeps: true on project_cheerio_crawler_ts in the templates manifest, so the CLI installs with --omit=optional. rolldown's platform binding is an optional dependency:

$ ls node_modules/@rolldown
pluginutils            # @rolldown/binding-darwin-arm64 is absent

$ node -p "Object.keys(require('rolldown/package.json').optionalDependencies).slice(0,3)"
[ '@rolldown/binding-darwin-arm64', '@rolldown/binding-android-arm64', ... ]

npm install --include=optional fixes it:

Test Files  1 passed (1)
      Tests  1 passed (1)

So the template ships a test script and a CI workflow that runs it, while the CLI installs in a way that guarantees npm test fails on a fresh scaffold. Worth checking whether skipOptionalDeps is still needed for this template at all — it looks like it predates the toolchain now in use.

Same root cause bites again in the Dockerfile, whose second stage runs npm install --omit=dev --omit=optional. Any dependency with a native optional binding — impit, for one — is silently missing at runtime on the platform.

Third symptom: --source github creates a repo whose CI is red on the initial commit

apify create <name> --template project_cheerio_crawler_ts --source github --git-repo <owner>/<repo> pushes an initial commit that does not include package-lock.json:

$ git ls-files | grep package-lock
                              # nothing

$ ls package-lock.json
package-lock.json             # on disk, just never committed

$ git check-ignore -v package-lock.json
                              # not ignored either

The template's own .github/workflows/test.yaml uses actions/setup-node with cache: npm and then npm ci, both of which require a lockfile. So the very first CI run on a brand-new repo fails:

Run actions/setup-node@v7
##[error]Dependencies lock file is not found in /home/runner/work/<repo>/<repo>.
Supported file patterns: package-lock.json,npm-shrinkwrap.json,yarn.lock

A new user's first experience of the repo the CLI just made for them is a red X on GitHub, on a commit they did not write.

Fix: commit package-lock.json in the initial commit. It should be committed anyway — npm ci depends on it, and it is what makes the CI cache work.

Suggested check

A post-create smoke step would catch all three: node satisfies engines.node, install completed without unresolved warnings, and — for --source github — the initial commit contains what the shipped workflow needs. Failing loudly at create time is far cheaper than each user rediscovering this.

Environment: apify-cli/1.10.0 (d227b1f), darwin-arm64, node 24.18.0, npm 11.16.0.

[l2ysho]

Scope split, for whoever picks this up: the two causes behind symptom 1 are template-side and are now tracked in apify/actor-templates#941 — skipOptionalDeps: true in templates/manifest.json, and the same --omit=optional in the template's Dockerfile (which additionally breaks impit on the platform).

What stays here is the CLI behaviour: printing Success without checking engines.node or the install warnings, and --source github pushing an initial commit with no package-lock.json while the shipped CI workflow needs one.