Add jest.config.js when running yarn rw upgrade

[RobertBroersma]

Soon #805 will be released, which will require the user to create jest.config.js for every "side" they want to run tests for.

@Tobbe had a great suggestion:

And I wonder, could we make yarn rw upgrade add default jest.config files if they don't exist?

@thedavidprice Can we? Should we?

[thedavidprice]

Ah, this leads to some questions I had about #805 and wanted to discuss further:

1. is the (now merged) PR backward compatible? E.g. if we release v0.14.0 today and people upgrade, can they still run yarn rw test?
2. For new installations, should the config be included in the CRA template? (If so, is it already added?)
3. had a question about docs but saw this https://github.com/redwoodjs/redwoodjs.com/issues/162 Thanks!
4. If jest.config.js is required, has this been added as a diagnostic check to project structure?

How to add the code, e.g. should we use yarn rw upgrade
If this is effectively a one-time code change required to upgrade, I believe the way to handle that is via what's called "code mods" as it's something to be done once. We could include code-mods in the upgrade process indeed!

So what if we added a flag to the upgrade command, something like yarn rw upgrade --mod, which would do a couple of things in addition to upgrading to the latest package:

• check for the latest version to upgrade ...
• ... run a specific code generator tagged for that version
  • with all the same behaviors like, check for existing, fail gracefully, etc

Maybe this is an opportunity to explore using https://plopjs.com/ ?

[RobertBroersma]

@thedavidprice

1. No. They'll need to create the Jest configs.
2. Yes! No, it's not added yet. Good one, totally forgot about that.
3. Cool!
4. I don't think so.

Regarding adding the code with yarn rw upgrade:
Reading all this I think I may have merged a bit recklessly 😬

If you're looking to release soon, we could consider reverting the PR and adding the modding stuff to it?

Agreed about all the other stuff you said!

[thedavidprice]

Reading all this I think I may have merged a bit recklessly

^^ ha! I wouldn’t say "recklessly". We're definitely all LearningTogether™ and this probably just highlights the need for creating some rough list of things to have in the back of our mind with each PR: docs, backward compatibility check, CRA template, a final summary of code being merged, etc. TBD

There's no release coming today or tomorrow, so I'd say we're good moving forward with a plan — maybe something like this:

1. Add the new config code to the CRA template repo
2. We'll use that PR/commit as the example to point to in the Release Notes for v0.14.0 (within a "How to Upgrade" section). This is a relatively easy thing to communicate it seems.
3. All the rw upgarde, code-mod, plopjs stuff gently placed in the hopper for another time. It would be a great thing to have especially > v1.0, but until then we're managing just fine I think.
   • on this note, maybe the exploration to be done is how to automate a code-mod update that's sync'd with changes to the CRA repo... that could be cool, right?

[RobertBroersma]

Sounds like a plan!

I think we can automate a bunch of the checks you mentioned, but I digress...

I'll add those configs to the template repo!