Scaffold examples

[frandiox]

Depends on #1549

Adds support for scaffolding projects based on examples (templates were already supported):

h2 init --template multipass
npm create @shopify/hydrogen -- --template multipass

h2 init --template demo-store

If the example uses the --diff flag, then it applies it on top of the skeleton template.

Note: examples are downloaded from the latest release, not from main branch. Therefore, it currently only works with express, multipass or customer-api until we make a new release with the new examples.

[benjaminsehl]

Do you have a flag here for supporting JavaScript instead of scaffolding TS? Or will that be a separate PR?

Did we decide on whether we want to use the full config flow or not? Or with this command is that all a part of it (e.g. this command kicks off the config flow, but uses this to modify the skeleton)

[benjaminsehl]

If the example uses the --diff flag, then it applies it on top of the skeleton template.

It feels like --diff should do the diff, but we should default to doing it with the skeleton … or else the flag should be like --verbose or something. Weird that diff would mean "I don't want the diff"… or am I misunderstanding?

Note: examples are downloaded from the latest release, not from main branch. Therefore, it currently only works with express, multipass or customer-api until we make a new release with the new examples.

Is this a decision or a constraint? Is it possible for us to change that?

[blittle]

Is this a decision or a constraint? Is it possible for us to change that?

I don't think the examples are published to npm, so the only way to get them is by downloading them from Github.

[blittle]

Running h2 init --template express --language=js doesn't actually produce a project in JS

[frandiox]

@benjaminsehl

Do you have a flag here for supporting JavaScript instead of scaffolding TS? Or will that be a separate PR?

It prompts if you want TS or JS, or you can pass --language js to skip the prompt.

Did we decide on whether we want to use the full config flow or not? Or with this command is that all a part of it (e.g. this command kicks off the config flow, but uses this to modify the skeleton)

It uses the prompts we had for --template demo-store originally, which is only JS/TS and install deps. The other ones are not guaranteed to work (although very likely they should work since it's skeleton-based).

If the example uses the --diff flag, then it applies it on top of the skeleton template.

It feels like --diff should do the diff, but we should default to doing it with the skeleton … or else the flag should be like --verbose or something. Weird that diff would mean "I don't want the diff"… or am I misunderstanding?

I'm not sure I understand what you're saying. The --diff flag is only for us, Hydrogen developers, to use in our examples folder. It shouldn't really be needed by users. It basically tells our CLI "run the dev command for a project that is already a diff and should be applied on top of skeleton".

Note: examples are downloaded from the latest release, not from main branch. Therefore, it currently only works with express, multipass or customer-api until we make a new release with the new examples.

Is this a decision or a constraint? Is it possible for us to change that?

Both, really. This comes from the time we had --template demo-store. It basically allows us to download the compressed tarballs that GitHub creates for releases (like this one) instead of downloading the whole monorepo using Git. Also, it allows us to ensure templates/examples are working before we release them as a way of versioning, instead of making them available to download with each commit to main branch. It's only a problem for the first time they are released, really. From there we shouldn't notice any issue.

---

Running h2 init --template express --language=js doesn't actually produce a project in JS

@blittle Oh, the express example is a bit weird because it uses server.js and tsconfig.json. Will fix it for this one 👍

It works with the other examples already (those with server.ts and tsconfig.json) -- we keep d.ts even in JS projects: