* fix: keep the template's identity out of generated apps
Scaffolding rewrote the manifest more than it needed to. The generated app
was given `version: 0.1.0` and `private: true`, discarding the record of
which template release it came from, while `displayName` and `description`
survived — so a project called `crm` was still labelled "Default Template".
Now only the identifying fields are touched: the name becomes the app's, the
display name, description, and publish metadata are dropped, and everything
else is kept as packed.
Preserve the database lifecycle switches in `.env.local`. `DB_MIGRATIONS_AUTO_RUN`
and `DB_SEEDS_AUTO_RUN` were already carried over correctly, but removing the
database keys around them stripped the bodies out from under headings like
`# Database`, leaving comment blocks describing nothing. Those blocks are now
dropped with the keys they documented.
Synchronize `nocobase.defaultTemplateVersion` with the package version during
a release. changesets rewrites `version` but knows nothing about the
`nocobase` block, so the two drifted on every release: the template published
0.0.1-beta.2 while still declaring 0.0.1, and every application generated from
it inherited the stale value. The release workflows now run
`scripts/sync-template-version.mjs` between `changeset version` and the release
commit, so the aligned value is both published and committed back.
The field means two different things and the docs now say so. In a derived
application it records a completed source upgrade and stays hand-maintained;
in the template package it mirrors `version` and must not be edited by hand.
Note in the SDK compatibility check what has to change before it can be
re-enabled: `supportedDefaultTemplateRange` still declares the v2 range
`>=3.0.0 <4.0.0`, which no v3 version can satisfy.
* chore: add changeset for the create-app fixes
PiEgg