Admin UI static building

[emmatown]

No description provided.

[changeset-bot]

✅ This PR has a changeset ✅
Latest commit: cf8a5bc

Click here to learn what changesets are.

[emmatown]

This is mostly ready but I have some questions about the CLI @jesstelford:

• Why are we using the CLI to execute custom servers? From what I understand, a large part of the reason behind using a custom server is being able to run keystone programmatically and using a CLI to execute it defeats that. I'm especially confused because the CLI was modeled after Next's and Next doesn't execute custom servers, people just run node on the server file.
• Why is the --out flag a thing over an export in index.js? I really like what Next does where you specify the output folder in the Next config so for Keystone, I would think it would be a distDir export from index.js. It's especially nice because it removes the problem of having to specify the dist directory in two commands and in a custom server file if you have one.

[jesstelford]

Why are we using the CLI to execute custom servers?

No particular reason. It's basically a very thin wrapper over just executing the file with node directly.

Why is the --out flag a thing over an export in index.js?

Note that next allows specifying that directory on the command line too (-o):

next export --help

    Description
      Exports the application for production deployment

    Usage
      $ next export [options] <dir>

    <dir> represents where the compiled dist folder should go.
    If no directory is provided, the 'out' folder will be created in the current directory.

    Options
      -h - list this help
      -o - set the output dir (defaults to 'out')
      -s - do not print any messages to console

I don't mind there being a config option too. Personally, I go back and forth between preferring the CLI option and the the config file option for various utils. I like the atomicity of the CLI option - I can run the CLI with different options and not worry about a config file getting in the way. But on the other hand, when there are lots of options, a config file is much easier to read and edit ¯\_(ツ)_/¯

[emmatown]

No particular reason. It's basically a very thin wrapper over just executing the file with node directly.

How would you feel about removing it because I feel like it's confusing because you can't use the CLI to pass in options because you have to pass it into keystone.prepare so it misleads people into thinking the CLI is doing something?

[jesstelford]

What do think about making one of the cypress test projects do build and start instead of running dev so it essentially does exactly that?

Yeah, great idea!

Copy one of the existing tests to a new test file so it's isolated, and we can build on it in the future 👍

[emmatown]

Copy one of the existing tests to a new test file so it's isolated, and we can build on it in the future 👍

Do you mean one of the jest tests? I'd rather not do that right now because those particular tests do so much mocking and the internals will change soon because of the servers stuff so the tests would have to change really soon because of that. After the servers stuff is done, I'd like to change those tests to not do very much mocking at all and test everything nicely.

---

I've made it so the login integration tests run keystone build and start the server with NODE_ENV=production on CI so we have a smoke test for the build and prod start.

I've also fixed the output directory stuff and updated the docs in the root README so it's accurate with what's currently implemented.

[jesstelford]

Love it! Just a couple cleanups and it's good to merge 👍

[jesstelford]

Looks like that test you added is catching a bug already! 🎉