feat: improve test command, support dotenv files, add postcss

[amcgee]

This is an upgrade to the test command which adds support for jest config overrides, provides nice testing defaults, and adds support for --updateSnapshot, --coverage, and --watch to the test command.

This also adds support for specifying environment variables in .env files (including .env.local, .env.<mode>[.local] (mode == production, development, or test), for all three build/test/start commands

This does modify the behavior of the compiler somewhat - we now only bundle apps into a single file, not libs (this might change again in the future). We also only support CJS module loading (for now) because of an issue with CJS named exports in static dependendency resolution (see the code comment and the rollup issue)

This also adds support for postcss so that we can more easily port CRA apps to the platform. It supports import 'my.css' for global styles, as well as import styles from 'my.module.css' for CSS module support (filenames must have the extension .module.css)

Finally, I've patched up a few small issues in the shell, such as an omitted typeface-robotto and including more favicon variants

These changes were influenced by the effort to port Usage Analytics to the platform, see dhis2/usage-analytics-app#94

[netlify]

Deploy preview for dhis2-app-platform ready!

Built with commit 1e1efbe

https://deploy-preview-52--dhis2-app-platform.netlify.com

[varl]

Nice improvement. 👍

Looks good all-in-all. Very nice getting bundle analysis built-in. 🔬

I'm a bit way about misuse of .env files, though that is up to the consumer. The 12-factor app principles don't always apply to us, nor should they, though some of the points are general enough to apply where we think they make sense.

I believe the configuration parts is one such area: https://12factor.net/config

The dotenv authors discuss it a bit in their FAQ as well: https://github.com/motdotla/dotenv#faq

Having .env.development, .env.test, env.development.local etc. is an anti-pattern, and not something I want us to endorse.

[amcgee]

I'm a bit way about misuse of .env files, though that is up to the consumer. The 12-factor app principles don't always apply to us, nor should they, though some of the points are general enough to apply where we think they make sense.

I think I agree here - it's a tradeoff, though, since .env files I think can make development (and particularly shared development) easier. I went for CRA compatibility here, to minimize the modifications necessary to i.e. usage-analytics-app.

I'm onboard with removing at least the per-environment env files, but would be curious what the "right" way to implement environment defaults/overrides should be in the platform - I know we'll be getting rid of this use of source-local HTTP requests soon, so we could omit the REACT_APP variables, but there will be different configurations of DHIS2_BASE_URL between development and production at least for the foreseeable future.

@varl what do you envision - no support for dotenv or support for only one dotenv (possibly with .local overrides)

[varl]

We need to think a bit about it. For instance, what is an environment? My computer for example is a development environment, and therefore it should not be allowed to act as a production environment.

Generally I think that a .env.template with all variables committed to the repository, and an ignored .env file is enough. The .env file has the environment variables for the current environment. That's it. This doesn't really work for us since we cannot e.g. have a .env file on Travis for CI, or one on Netlify or one on the production instance that can be read by the app.

CRA does not use the environment files for environments in the strictest sense, it uses it for configuration for different modes for the intended environment, which solves the problems above in exchange for a bit of a mess of files in the app repo.

Anyway, pardon me for bringing up this topic in this PR. I think this is good for now.

[amcgee]

@varl it's a very fair point since this adds support for .env[.mode][.local] files, should we pull that support and just allow .env for now or merge this with support for all variants?

[amcgee]

The advantage of allowing multiple mode-targeted .env files is that you can, for instance, specify http:https://my-server.com for development and then revert to ../../../ (or whatever) in production. We could set this automatically, but I also think there might be situations where a production build would want a custom root url

[amcgee]

(p.s. thanks for the feedback!)

[varl]

@varl it's a very fair point since this adds support for .env[.mode][.local] files, should we pull that support and just allow .env for now or merge this with support for all variants?

I thought about that too, and to be pragmatic about it; .env[.mode] makes a lot of sense for configuration purposes. The case for .env[.mode][.local] is weaker as .env.local covers the most reasonable use cases.

In the end, having support for it doesn't mean we have to use it, so we can safely leave it in.

[HendrikThePendric]

I've left one comment in the code that I think needs to be addressed before this is merged.

[ismay]

In the end, having support for it doesn't mean we have to use it, so we can safely leave it in.

Nice. I personally like using this to have a standard way to point to a dhis2 backend. I don't like the approach we used before with the dhis2 config that lives outside of the repo, on your system somewhere. The .env files make way more sense to me.

[amcgee]

I've left one comment in the code that I think needs to be addressed before this is merged.

@HendrikThePendric removed the offending file, thanks for catching that - should be good to go now!

[amcgee]

I'd really like to get this in - @HendrikThePendric I think your request has been addressed, let me know ASAP if it hasn't, otherwise I'd like to merge this first-thing tomorrow!

[HendrikThePendric]

LGTM

[amcgee]

Thanks all for the feedback!

[dhis2-bot]

🎉 This PR is included in version 1.4.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀