Polish potential

[brillout]

Some neat low-hanging fruits IMO.

• Always generate .gitignore.

• Initialize git repo. (With --skip-git option to avoid git initilization.)

• Publish as create-bati (I just sent invitations to Joël and Muhammad) instead of @batijs/create-app.

• Replace:

  This app has been created with Bati using the following flags: --vue --express --google-analytics --eslint --prettier.

  With:

  Generated with Bati (version 226) using this command:

  pnpm create @batijs/app --vue --express --google-analytics --eslint --prettier

• If my-app/ already exists then create my-app-2/.

  • (I think it's a great idea to not ask for a directory name, as the user can simply mv my-app some-name.)
  • Idea: maybe generate a small UID my-app-812dh/. Comfy to avoid conflicts when publishing/cloning git repos, such as reproductions.

But I don't know: maybe some/most of it isn't as trivial to implement as it seems.

[magne4000]

• Always generate .gitignore.

This should already be the case (it's even tested). Do you have a particular combination of flags that resulted in missing .gitignore?

[phonzammi]

I've tested, and the .gitignore file is missing when scaffolding from https://batijs.dev/, e.g. pnpm create @batijs/app --react

But, it's present when we scaffold using cli, like pnpm run cli --react

[magne4000]

Ho, it probably means that it's not packaged

[magne4000]

Fixed by #315

[magne4000]

#314

[brillout]

Neat 😍

FYI seems like the 227 release acc7fd0 didn't went through: both https://www.npmjs.com/package/@batijs/create-app and https://www.npmjs.com/package/create-bati are still on 226.

[magne4000]

Fixed

[brillout]

I just tried with pnpm create bati@0.0.232 --telefunc --express --react and it seems like .gitignore is still missing. Also the markdown for the Bati version seems to be malformed:

Generated with [Bati](https://batijs.dev)  using this command:

Now that we initialize a Git repo, maybe we can also create an initial commit. This is for example what create-vike does: https://github.com/vikejs/vike/blob/15e3f92a64a13bbd933a87e6c8c1fb36359d46c6/boilerplates/index.js#L178-L208.

(Unrelated: I wonder whether we should add @latest to the command. So far the https://vike.dev/new page only adds @latest for npm. I don't know whether it makes a difference for other package managers. I guess there is a trade-off here between accuracy and speed.)

[brillout]

(Unrelated: I wonder whether we should add @latest to the command. So far the https://vike.dev/new page only adds @latest for npm. I don't know whether it makes a difference for other package managers. I guess there is a trade-off here between accuracy and speed.)

Actually, how about pnpm create bati@0.0.232? It's not only the most accurate but also the fastest (no need to lookup if it's already installed). I guess we should then publish to 232.0.0 instead of 0.0.232 (otherwise I can already see users asking whether Bati is production ready).

[magne4000]

I just tried with pnpm create bati@0.0.232 --telefunc --express --react and it seems like .gitignore is still missing

Indeed, I forgot to explicitly include it in @batijs/cli. Will be fixed as part of #318

Also the markdown for the Bati version seems to be malformed

I'm checking it

Now that we initialize a Git repo, maybe we can also create an initial commit. This is for example what create-vike does: vikejs/vike@15e3f92/boilerplates/index.js#L178-L208.

👍

(Unrelated: I wonder whether we should add @latest to the command. So far the vike.dev/new page only adds @latest for npm. I don't know whether it makes a difference for other package managers. I guess there is a trade-off here between accuracy and speed.)

I did not found recent documentation implying that it still needed even with npm

[brillout]

Everything works now ✨

I did not found recent documentation implying that it still needed even with npm

I was using Bati with pnpm@9.5.0 and it was using an old version (adding @latest wasn't working either and I had to explicit set the version). I just tried again with pnpm@9.6.0 and it correctly picked the latest version. Maybe it was a 9.5.0 bug. Let's see if I stumble upon the issue again.

Btw. I was thinking to always append my-app-{UUID} but I can see that to be a matter of taste. No strong opinions here. (Although I'd argue that appending a counter instead of a "UUID" in case of conflict would then make a little more sense if we don't always append a UUID.)

[magne4000]

I was using Bati with pnpm@9.5.0 and it was using an old version (adding @latest wasn't working either and I had to explicit set the version). I just tried again with pnpm@9.6.0 and it correctly picked the latest version. Maybe it was a 9.5.0 bug. Let's see if I stumble upon the issue again.

I have the impression that pnpm seems to cache for a few seconds or a minute packages used by pnpm create (I don't know if it's really the case though).
create subcommand exists for the sole purpose of scaffolding, so I would say that every package manager probably defaults to fetching fresh packages in most cases.

Btw. I was thinking to always append my-app-{UUID} but I can see that to be a matter of taste. No strong opinions here. (Although I'd argue that appending a counter instead of a "UUID" in case of conflict would then make a little more sense if we don't always append a UUID.)

Implementing a counter required a little more logic, so I just went for the laziest solution here

[brillout]

create subcommand exists for the sole purpose of scaffolding, so I would say that every package manager probably defaults to fetching fresh packages in most cases.

That's what I thought as well, but npm used to cache too much (I don't know if it still does). FYI, in the early days, Vite decided to add @latest for npm as well (and still does).

Let's see how package managers behave in practice. We could already add @x.y.z for increased speed, but I don't know whether that triggers package managers to use their cache then. (In theory it's the most reliable and fastest solution, albeit a little bit ugly if it turns out to be useless in practice.)

Implementing a counter required a little more logic, so I just went for the laziest solution here

I see.

Anyways, I'm just thinking out loud and, as always, and feel free to decide otherwise