Consider exporting the functions behind keystone start etc.

[frantjc]

I added Keystone to an application that starts Keystone by spawning a child process like so:

// server.js
// My custom express server stuff.

// Also run Keystone.
const bin = path.join(__dirname, "node_modules/.bin/keystone");
const cmd = cp.spawn(bin, ["start"], {
  stdio: "inherit",
  cwd: __dirname,
});

The downside of this is that I had to stop using a tool like @vercel/ncc to minify my application's build, instead having to package the application with the entirety of it's node_modules so as to allow node_modules/.bin/keystone to have all of its dependencies. This more than quadrupled the size of my application's final build.

It would be nice if I could instead import a function to start Keystone.. something like:

// server.js
// My custom express server stuff.

// Also run Keystone.
const { start } = require("@keystone-6/core/scripts");
start();

[dcousens]

@frantjc what are your thoughts on #8995

[frantjc]

As you suggested at the end of that thread, exporting this function:

https://github.com/keystonejs/keystone/blob/main/packages/core/src/scripts/start.ts#L16

As well as this one (skipped over this detail in my initial post for simplicity):

https://github.com/keystonejs/keystone/blob/main/packages/core/src/scripts/prisma.ts#L12

Would satisfy my use case, I think.

---

EDIT:

What I fear from a lack of understanding of Prisma and Keystone is that, even if those are exported, potentially those functions rely on a specific layout of the cwd that a bundler like @vercel/ncc wouldn't "play nicely" with. For example, I'm looking here:

keystone/packages/core/src/scripts/start.ts

Lines 22 to 35 in 2e3be07

	// TODO: this cannot be changed for now, circular dependency with getSystemPaths, getEsbuildConfig
	const builtConfigPath = getBuiltKeystoneConfigurationPath(cwd)
	// this is the compiled version of the configuration which was generated during the build step
	if (!(await fs.stat(builtConfigPath).catch(() => null))) {
	console.error('🚨 keystone build must be run before running keystone start')
	throw new ExitError(1)
	}
	const config = getBuiltKeystoneConfiguration(cwd)
	const paths = getSystemPaths(cwd, config)
	const { getKeystone, graphQLSchema } = createSystem(config)
	const prismaClient = require(paths.prisma)
	const keystone = getKeystone(prismaClient)

Because it seems to require some files here dynamically, I'm not sure if the bundler would hook everything up correctly.

So, with that in mind, taking things a step further, it'd be extra ideal if those function didn't depend on being ran from a cwd that has certain files in certain locations relative to it, e.g. instead of:

const { start }= require("@keystone-6/core/scripts");
start(process.cwd());

One could run something like:

const config = require(".keystone/config");
const { start }= require("@keystone-6/core/scripts");
start(config);