chore(core): Add jest config back to rwjs/core

[dac09]

Related to #4334

Adds jest config for rwjs/core

We had a test in the @redwoodjs/core but no jest config, and no script to actually run it. :S Adds jest stuff back so the test actually runs (also updated the test)

[thedavidprice]

Shouldn't this include a test for stubbing an env var without a value to prevent another regression?

[dac09]

If you look at the test DP, unfortunately it doesn't seem possible (to me, right now) to test this without running a full webpack build when we use the third party dotenv plugin

I was able to add the extra test in the previous PR because I'd changed our code that handled dotenv loading.

[thedavidprice]

@dac09 Understood, and this brings up some of the things I wanted to discuss related to #4334

1. I suggest we prioritize implementation according to preventing regression. This is how we ended up here in the first place — an innoucuous one line config change that broke apps. We need to prevent the same break from happening again.
2. So I'm all for custom implementation when it allows us to test and prevent regression
3. As far as removing DotEnv, I wanted to discuss edge cases where removing it might still break existing apps. Personally, I can't think of any, but the problem is we can't test for it. So my suggestion was to leave it enabled as is — or, maybe, we schedule it for deprecation and testing via the ultimat RC before 1.0.0 release.

[thedavidprice]

@dac09
I think getting this in is better than not, but it doesn't really resolve my concerns re: preventing regression and having coverage that simulates the behavior we intend.

I'm approving this, but I do want us to prioritize a next step, which would preferrably be a PR (but Issue ok).

Here's the approach I suggest as a next step:

1. outline the behavior we intend and expect (I've started that process by auditing existing behavoir over here Audit Web Environment Variables DX and Current Functionality #4503)
2. creating the tests we need to cover all expected behavior (even if psuedo code): toml, prefix, stubbing, should not exist, etc.
3. then modifying the config and plugins to a) be able to run the tests and b) get the tests passing

We'll need to address:

• contexts; e.g. local dev vs production deploy
• currently .env.default (package dotenv-defaults) is configured via CLI package code and not webpack
• reconciling the two webpack config approaches we currently have — define plugin vs. DotEnv — and how to integrate/resolve (because we don't need both, do we?)

[netlify]

✅ Deploy Preview for redwoodjs-docs canceled.

Name	Link
🔨 Latest commit	a4b0f7f
🔍 Latest deploy log	https://app.netlify.com/sites/redwoodjs-docs/deploys/627143548031c90008e0a121