Replaced top-level .gitignore with the one in the app/.

[Martinsos]

1. Not much sense in having a top level .gitignore, I am guessing it is a leftover from before.
2. app/ should have its own .gitignore. Now it has one, and I used the one that comes with wasp new by default.
3. The big change now is that migrations are no longer ignored. Which is good because they shouldn't be! They should be part of the project. That said, it is interesting that open-saas doesn't come with any migrations already. Are we ok with that? I thought that some time ago we had one big initial migration, but we dropped that? How should we approach this now that I updated these gitignores, is this problematic now, what do we want to do?

[vincanger]

@Martinsos I assumed it was better not to include the migrations because the user should be a getting a clean template. What would be the advantage of including migrations? Better DX for contributors? Wouldn't it still work without migrations? Then they would just create their own initial migration the first time they run wasp db migrate-dev.

[Martinsos]

@vincanger you are ok with the changes I made in this PR though, right? We do not want them to have migrations gitignored.

What we are discussing now is, do we put migrations/ dir in the template, right?
Yeah about that I am not sure hm. You are right, they can always do that initial migration on their own. On the other hand, if there is an initial migration already, that also shouldn't hurt. So I think for them it doesn't matter. The question is then, what is easier for us? We either have to make sure not to commit migrations dir, or we have to make sure we keep squashing it into a single migration, because if they get a bunch of them, that is ugly (although also wouldn't be an issue). Unless we had our own .gitignore for it, but then they also have it -> we could though have Wasp remove that top level gitignore when creating the template via wasp new -t saas, that is the third option (sounds a tiny bit complex though).

[vincanger]

@Martinsos yes, I agree migrations shouldn't be in gitignore.

What we could do is create a GH action that removes the migrations dir when pushing / merging to main. WDYT?

Edit: Actually, that sounds like it could get problematic. Maybe it's best we just remove migrations before pushing?

[Martinsos]

@vincanger yeah that does sounds tricky you are right!

I don't see a super neat solution. We could do stuff like define pre-commit hoooks that ensure migrations dir doesn't exist and what not, but I am not sure we should be spending time on that now. The easiest maybe is just that we agree we will not be committing migrations dir. At some point we will make a mistake and we will submit it, but no big deal. Once we get frustrated with this enough we can figure out how to improve the process.
In the meantime, it can be enough to write down in CONTRIBUTING.md that we don't want to commit migrations.

[Martinsos]

Ok, so I created a PR here that adds a warning to CONTRIBUTING.md: #138 .

Another idea: if we do that thing with having two dirs, one template and one open-saas-sh, then we can add top level .gitignore next to them that will gitignore template/app/migrations/! That will work well for us, but won't be pulled in with the template.

[Martinsos]

@vincanger anything else you need from my side here? I believe I covered all that you asked.