luckyframework
Consider dropping crystal init during setup
Right now when you run lucky init, we run crystal init app NAME under the hood. It's nice because it gives us a default structure, and a ton of things like setting up the src, and spec folders and such.
The issue is right after we do that, we basically remove almost all of it.
https://github.com/luckyframework/lucky_cli/blob/0b5b8fb25d8fc45d3cbc0334853daf45a1075d87/src/generators/web.cr#L107-L138
We used to even have this https://github.com/luckyframework/lucky_cli/commit/45f35290dae282610ea6aa5012b31861c792a03e because Crystal would default generate a travis CI, but then we started using Github, and then later versions of Crystal stopped generating that.
We're also at the mercy of whatever naming conventions, or bugs may appear in the crystal init.( ref )
Related: https://github.com/luckyframework/lucky_cli/issues/735
In regards to that issue, if we just generated our own structure out of the box, we'd keep control and flexibility to what goes in to an app.
The main downside would be that this also opens us to bugs with all the different permutations of app type (i.e. browser, api, auth, etc...), it's possible we miss something, or similar to the Crystal naming bug, we end up creating our own bugs with naming....
One of the patterns I've come across that I like here is that I treat crystal init as an overlay to the existing repo codebase
https://github.com/grepsedawk/sharded.cr/blob/main/.github/workflows/init#L18-L19
I take all the "my files" and copy crystal init's files over those, with the no clobber flag. This allows me to (more) plainly build a directory with files to override default shard files.
