manifest: 16 JS/TS templates have name field different from id — apify create -t <id> fails

[DaveHanns]

Problem

In templates/manifest.json, 16 JS/TS templates have a name field that's fundamentally different from id:

id (canonical, matches dir)	name (legacy)
js-empty	project_empty
js-start	getting_started_node
js-crawlee-cheerio	...
js-crawlee-playwright-chrome	...
... (12 more JS/TS entries)	...

The Python templates all follow id == name, so this is a JS/TS-specific historical drift.

The Apify CLI's getTemplateDefinition() at src/lib/create-utils.ts:36 looks up templates only by name, not by id. Users who reason from the manifest, from directory names, or from any modern documentation will run:

$ apify create -t js-empty my-actor
Error: Template "js-empty" not found. Available: project_empty, getting_started_node, ...

Even though js-empty IS a valid template — the user has to know to look up the legacy project_empty name.

Proposal

Coordinated changes across two repos:

1. apify/actor-templates (this repo) — manifest change

For each of the 16 affected entries, rename name to match id, and add an aliases: [old_name] array carrying the previous value for back-compat:

{
  "id": "js-empty",
  "name": "js-empty",              // changed from "project_empty"
  "aliases": ["project_empty"],    // NEW — preserves old `-t project_empty` callers
  ...
}

2. apify/apify-cli — companion lookup change

Update getTemplateDefinition() at src/lib/create-utils.ts:36 to also match on the aliases array when name doesn't match, so existing apify create -t project_empty callers continue to work through the alias.

Both PRs should ship together (order: templates first, so the CLI change has real aliases to match against).

Alternatives considered

• Just changing the CLI lookup to accept id instead of name — cleaner but breaks any user who scripted around name field values.
• Just changing the templates without CLI changes — breaks anyone using the legacy -t project_empty invocation.
• The proposed alias-based migration preserves both call sites indefinitely with no user-visible break.

Impact

Low (cosmetic / discoverability). Users who don't know the legacy names get "template not found" for a template that IS in the manifest. Agents that fetch the manifest to enumerate templates hit the same wall.

Related

• Cross-refs: apify-cli lacks in-tool template discovery (apify create --list) — separate issue against apify-cli. If discovery lands via manifest fetch, the manifest becomes the source of truth and this naming drift becomes user-visible.

---

Surfaced during an evaluation of Apify surfaces for agent-driven Actor development.