fix(create-astro): use CLI version tag to determine astro version

[apatel369]

Changes

Closes #12506

This PR fixes issues with installation messages in create-astro by using the tag provided in CLI arguments (e.g. @beta) for determining astro version.

All these commands now show the correct version of Astro in installation.

pnpm create astro@beta
pnpm create-astro@beta
npm create astro@beta
npm create-astro@beta
yarn create astro@beta
yarn create-astro@beta

[

installation.message.fix.mov

](url)

Testing

Manually tested by running local package with and without @beta

Docs

N/A bug fix

[bluwy]

I don't think this is quite right. The ref is a specifier for a git ref, eg the "next" branch. The specifier used to fetch versions is the npm tag, so it doesn't necessarily match

[apatel369]

I don't think this is quite right. The ref is a specifier for a git ref, eg the "next" branch. The specifier used to fetch versions is the npm tag, so it doesn't necessarily match

Thanks for reviewing this! Could you clarify what should be the correct tag value for the next branch? I was under the impression that the 'next' tag is currently being used for pre-releases. I referred to the CONTRIBUTING.md

[apatel369]

I don't think this is quite right. The ref is a specifier for a git ref, eg the "next" branch. The specifier used to fetch versions is the npm tag, so it doesn't necessarily match

Currently, we are using beta tag for next branch so using that solves the issue as seen in the video.

[delucis]

I agree with @bluwy: the --ref flag is intended to select the version of templates from GitHub based on branch naming. For example, if there was a 2025 template being developed on a new-template branch, you could use pnpm create astro --ref new-template --template 2025 to scaffold a project using it.

In the current moment, the next branch happens to align with the beta tag on npm (more or less, because the branch can also be slightly ahead), but it's not always the case.

Is there a situation where the current use of --ref next doesn't already pick up the beta version of Astro? I'd expect the versions specified in the template package.json to be used. (edit: I should read the issue first) I think Bjorn's suggestion there is to use the tag in the command create astro@beta. Not sure if we'd have direct access to that — might need parsing from the raw args.

[apatel369]

I agree with @bluwy: the --ref flag is intended to select the version of templates from GitHub based on branch naming. For example, if there was a 2025 template being developed on a new-template branch, you could use pnpm create astro --ref new-template --template 2025 to scaffold a project using it.

In the current moment, the next branch happens to align with the beta tag on npm (more or less, because the branch can also be slightly ahead), but it's not always the case.

Is there a situation where the current use of --ref next doesn't already pick up the beta version of Astro? I'd expect the versions specified in the template package.json to be used. (edit: I should read the issue first) I think Bjorn's suggestion there is to use the tag in the command create astro@beta. Not sure if we'd have direct access to that — might need parsing from the raw args.

Makes sense.
Does this mean we have incorrect dos right now?
Currently starting a new beta project asks you to run these commands: npm create astro@latest -- --ref next, pnpm create astro --ref next, yarn create astro --ref next. None of these includes @beta

[delucis]

Does this mean we have incorrect docs right now?

This does work (apart from the “Welcome” message from Houston saying v4) — it pulls the templates from the next branch on GH, which have dependencies updated to beta versions, so running that command does give you a new project using the beta release. For example, I ran it and got a package.json with the ^5.0.0-beta.12 version of Astro.

Running create astro@beta gives you the beta version of the create-astro package, which includes the recent changes to the questions the wizard asks.

One fix might be to remove the version from the “Welcome to Astro vX.X.X, NAME” message. At that point in the process we don’t know the Astro version yet. That said, it’s only an issue right now because we’re in a beta stage. But once Astro v5 is released, that message will again be correct for almost all users again. (Outside of this pre-release period, using --ref next is pretty rare.)

[apatel369]

One fix might be to remove the version from the “Welcome to Astro vX.X.X, NAME” message. At that point in the process we don’t know the Astro version yet. That said, it’s only an issue right now because we’re in a beta stage. But once Astro v5 is released, that message will again be correct for almost all users again. (Outside of this pre-release period, using --ref next is pretty rare.)

Thanks for the detailed explanation. Is there a way to determine the correct version to installed later in the process? If so, perhaps we could remove the Astro version number at the start and display it later in the process?

[delucis]

Is there a way to determine the correct version to installed later in the process?

I guess once the template is downloaded we'd know from the package.json?

[bluwy]

I think my initial idea for pnpm create astro@beta and knowing the "beta" part is by having that information inlined into create-astro at build time. But I think reading from package.json also works, whichever is simpler to implement.

That way we're reading the npm tag for create-astro and we can find the same for astro, not using --ref.

[apatel369]

Thanks to both of you for your great suggestions.
I am now parsing args to get the tag and fetching the Astro version based on that tag name. There is an edge case, though, where the user can pass the version number instead of the tag, i.e. [email protected]. How should we handle this case?