Use dope.sh to generate a testable app from production template

[infomiho]

Description

Based on #531

Fixes #524

This PR reuses the existing dope.sh to create a testable app from an app generated by wasp new app -t saas.

The changes are minimal:

• change Dummy to SMTP and use the correct email address
• setup Dotenv Vault

This allows for testing the app in production mode e.g. npx @wasp.sh/wasp-app-runner build.

This PR doesn't setup Stripe, analytics or similar. I think it's not really needed to smoke test the template. We have opensaas.sh with all the bell and whistles for that.

Contributor Checklist

Make sure to do the following steps if they are applicable to your PR:

• Update e2e tests: If you changed the /template/app, then make sure to do any neccessary updates to /template/e2e-tests also.
• Update demo app: If you changed the /template/app, then make sure to do any neccessary updates to /opensaas-sh/app_diff also. Check /opensaas-sh/README.md for details.
• Update docs: If needed, update the /opensaas-sh/blog/src/content/docs.

[cprecioso]

@infomiho haven't looked at anything here, but wanted to pop in; if we're going to be using dope.sh more extensively, might it make sense to migrate it to a more understandable (and less edge-casey) language? We can take advantage of the fact that node is already installed...

[infomiho]

@cprecioso I think that the natural journey of all of our scripts -> inline -> bash -> Node.js

I wouldn't do it in this PR though, I'd create an issue if we agree that we want to do it.

[cprecioso]

@infomiho My vote is to even do that before this PR here. As you see fit.

[Martinsos]

+1 for the idea of rewrite at some point but also big +1 for not doing it now, priorities again, dope.sh works fine and is tested through use, no need to shake that tree at the moment.

[sodic]

This is great! It solves the most annoying and the longest part of release testing (at least to me).

I do have some questions and suggestions, check the comments.

[sodic]

We have a very similar thing in opensaas-sh/tools. Can we consolidate them and somehow?

[infomiho]

They are actually quite different:

• opensaas-sh/tools script can use the template dir it has available on the disk
• template-test/toolsscript needs to run wasp new each time to get the template

[infomiho]

[sodic]

I'm not sure about the migration stuff. Shouldn't wasp db migrate-dev be part of testing too?

[infomiho]

Fair point! I'll remove the migrations from the diff since the tester needs to run wasp db migrate-dev.

[infomiho]

Good thing is that wasp-app-runner runs the wasp db migrate-dev command 😄

Again the trouble is - every time you test the app and you tweak something, the new diff will include the migrations again. So you'll need to delete the diff files manually. What do we think about that?

[infomiho]

I've now removed migrations dir (our users start without them) so we can test wasp db migrate-dev. I've also removed the package-lock.json (our users start without it) so we can see test the template as our users would use it.

Added extra lines in the .gitignore diff with explanations.

[sodic]

Why does this file have diffs. I'd expect it to be the same (apart maybe from !.env.valut):

• Shouldn't .env* be ignored in the template too?
• Why is .flaskenv in there?
• Why is env.project in there?

[infomiho]

We had this problem in different example apps - this is what Dotenv Vault automatically adds each time when you run npm run env:pull.

So if you are testing something and decide to modify the app e.g. you found some tweak that would help and run ./tools/diff.sh you'll end up with the .gitignore changes again. You now you have to revert the .gitignore changes manually if you want to keep it out of the diff.

So I decided to keep them in - they don't any harm and make the process less annoying.

[sodic]

Ok, fair enough, but can you put in a comment that explains this in the gitignore (basically what you said here).

[infomiho]

Added a comment 👍

[sodic]

Do we need to delete these?

[infomiho]

I think I did by accident - I was probably cleaning up stuff I thought we didn't need or something like that. I'll remove this 👍

[infomiho]

Correction - it looks like a bug with the dope.sh script, I'll investigate!

[sodic]

You might find this helpful: #523

[infomiho]

False alarm, it looks the Dotenv Vault addition of .env* below the !.env.*.example overrode the exception not to ignore those files - so it looked like the files were deleted when dope.sh ran.

I've asked Claude to explain with code:

Explanation by Claude

Root Cause: .gitignore Rule Ordering

In template-test/app/.gitignore, negation rules were placed before broader ignore patterns:

.env.*
!.env.*.example    # Un-ignores .env.*.example

.env*              # Re-ignores everything starting with .env (including .env.*.example)
!.env.vault        # Un-ignores .env.vault

Last matching pattern wins in gitignore.

How dope.sh Detects Deletions

# dope.sh uses git ls-files to list files
git ls-files --cached --others --exclude-standard

# Files in BASE but not in DERIVED go into deletions
comm -23 <(echo "${BASE_FILES}") <(echo "${DERIVED_FILES}") > deletions

With broken gitignore:

cd template-test/app
git ls-files --cached --others --exclude-standard | grep "\.env"
# Output: .env.vault
# Missing: .env.client.example, .env.server.example

The Fix

Reorder gitignore so negations come after broader patterns:

.env.*
.env*              # Ignores everything
!.env.vault        # Un-ignores specific files
!.env.*.example    # Un-ignores .env.*.example files

After fix:

git ls-files --cached --others --exclude-standard | grep "\.env"
# Output:
# .env.client.example
# .env.server.example
# .env.vault

Both BASE and DERIVED now have the files, so they don't appear in deletions.

[infomiho]

Now the file is empty - after I fixed the order in .gitignore 👍

[sodic]

Why is this here? How would the base-app end up in this folder?

[infomiho]

It's the side-effect of running wasp new to generate a new app based on the released Open Saas template. We decided to create the app in the base-app dir which we extract the app dir from. We clean it up - but just in case, I've gitignored it.

[sodic]

Hm, I don't think we should ignore it then.

If it doesn't get cleaned up, we want to see problems at their true source?

[sodic]

We should point the releaser to thsi from somwhere global (like the README.md or the release checklist).

[infomiho]

Linked to the README from the checklist https://www.notion.so/wasp-lang/0-X-Y-26818a74854c8094b1fdf42b3e9d25b8?source=copy_link#26818a74854c80439e0ae8bdd709b4d6

[sodic]

I guess this is workflow for updating/migrating.

Since the dope.sh README is now in a different place, can we elaborate that here? You can put it under the title: "If you need to update/migrate..."