Blitz: Make `blitz new` use the latest published template instead of what's installed globally

[flybayer]

What do you want and why?

Currently blitz new will generate a new app with the template version of what's installed. So if global blitz version is 0.17.0, then the new app template will be the template as of 0.17.0, but the actual blitz version inside the new app will be the latest blitz version.

That results in a bad and confusing user experience.

Possible implementation(s)

Instead of using the template packaged with npm, blitz new would download the new app template from the latest npm version and use that for new apps.

So if latest version is 0.21.0, a global blitz version of 0.17.0 should create a new app with the template in 0.21.0. The end result is the same as if the user upgraded the global cli version and then created a new app.

This may not be the best way. I'm open to suggestions for a better way!

Additional Details

The entry point for blitz new is this command file. And here is the actual app generator. The new app template files are here: https://github.com/blitz-js/blitz/tree/canary/packages/generator/templates/app

cc @aem

[aem]

I think what we really probably should do is prompt the user to globally upgrade Blitz if the version is out of date? If there were breaking changes in the generator/CLI packages between versions we could be trying to install a template that's incompatible with the globally installed CLI.

[flybayer]

@aem hmm yeah maybe so. If we do that, then we might as well change all our docs to use npx blitz new myapp so that npx takes care of always having the latest version.

Without doing that, we'd somehow have to download the latest template and install the latest generator package.

[aem]

could we add a pre-run step to prompt the user to upgrade if it's not the most current version? ask if they want to upgrade first, and if so do an (npm i -g|yarn global add) blitz before running the generator?

[flybayer]

Yeah that actually sounds pretty good!

[hardfire]

I like the ideas to

1. change the docs to use npx blitz instead of blitz. I personally have switched to doing this instead of using yarn or the global blitz
2. add a pre run step to upgrade (if they want to)

[engelkes-finstreet]

What do you think about letting the user choose which version he wants to install? I guess for now you always want to have the latest version but maybe you want to use some older versions in the future.

[flybayer]

@engelkes-finstreet that's not a bad idea, but definitely adds a good bit of complexity. I think we can just go with latest. If they want a specific version, they can do yarn global add[email protected]`

[danielrlc]

I like the ideas to

1. change the docs to use npx blitz instead of blitz. I personally have switched to doing this instead of using yarn or the global blitz
2. add a pre run step to upgrade (if they want to)

Using npx didn't work for me.

What did work was this:

yarn global add blitz@latest
blitz new myAppName

This fixed the problem of missing auth files and folders.

[abuuzayr]

I can work on this. Can I confirm that the recommended method when blitz new is run is to:

1. Check the global blitz version
2. Prompt user to upgrade "Your blitz CLI version is outdated. Upgrade? (y/n)"
3. If yes, upgrade their global blitz version and run blitz new
4. If no, cancel the blitz new command

[aem]

@abuuzayr that seems reasonable. I'd amend the prompt to have three options, something like:

1. Update my global Blitz installation
2. Don't update Blitz, but use npx to use latest version
3. Don't update Blitz, abort generation
4. Generate using my current version of Blitz (not recommended, X.Y.Z is K months old)

We should still let users generate using their local copy, but we should discourage it since it's the least desirable option. @flybayer seem reasonable?

[flybayer]

I don't think npx as an option makes that much sense, because usually you will have blitz installed globally or use npx, not both 🤔

I like @abuuzayr proposal with difference of allowing using the old version

1. Check the global blitz version
2. Prompt user to upgrade "Your blitz CLI version is outdated. Upgrade? (y/n)"
3. If yes, upgrade their global blitz version and run blitz new
4. If no, continue using old version

[Khaledgarbaya]

👋 I am no expert here, did you folks consider using the oclif auto-update?

[flybayer]

@Khaledgarbaya my understanding is that only works if the CLI is published as a binary, which we don't do 🤔

[Khaledgarbaya]

in that case, I think this from the npm codebase can help

[abuuzayr]

Thanks @Khaledgarbaya ! Will look into that for some inspiration.