Admin cli

[teleaziz]

Usage

$ npm install -g @builder.io/cli
$ builder COMMAND
USAGE
  $ builder COMMAND
...

Commands

• builder import
• builder new

builder import -k [PRIVATE KEY] -o [OUTPUT DIRECTORY]

Import your space to the local filesystem.

USAGE
  $ builder import -k [PRIVATE KEY] -o [OUTPUT DIRECTORY]


OPTIONS
  -k, --key Private key of the space you want to import

  -d, --debug  Optionally print debug information and progress bars.

  -o, --output  Optionally output directory, default to ./builder

DESCRIPTION
  This command will download a self-contained clone ( new IDs) from the target space and save it on the filesystem.

builder new -k [PRIVATE KEY] -i [INPUT DIRECTORY] -n [NEW SPACE NAME]

Create a new space from the your local builder directory, as a space under the root organization you specify.

USAGE
  $ builder new -k [PRIVATE KEY] -i [INPUT DIRECTORY]


OPTIONS
  -n, --name   The new space name

  -k, --key Private key of the root organization you want to import

  -d, --debug  Optionally print debug information and progress bars.

  -o, --input   Optionally input directory, default to ./builder

DESCRIPTION
  This command will create a new space clone from your local builder directory.

[steve8708]

I like to use a package fs-extra-promise which lets you use async/await for much better perf and parallelization

await fse.emptyDirAsync(`./${directory}/${modelName}`);

etc

[steve8708]

can make a big difference when doing things like this that are in a loop/forEach so you don't block the thread

[steve8708]

just note at times you'll need to use Promise.all too, e.g. above

// from
spaces.modes.forEach(...)
// to
await Promise.all(spaces.models.map(async ...))

[mrkoreye]

Maybe make this configurable via a flag that gets passed in so when we want to test new features we can deploy to qa and test it

[teleaziz]

I don't think this is possible in current configuration, the client is getting generated at build time using that specific endpoint, the plan is to eventually move all admin-sdk code from here to it's own package, where this could be possible

[mandx]

Suggested change

	const root = 'https://qa.builder.io';
	const root = process.env.ROOT_URL || 'https://qa.builder.io';

This way the root URL can be specified at any time at run/build time, and fallback to QA if it's not present.

Like if we do (example):

env ROOT_URL='https://production.builder.io' npm publish

in a Github action, published artifacts will always point to "production", regardless of what we use during development when running npm run whatevs. That also allows devs to run one-off commands against any environment, without having to change any code.

To make managing env vars easier during development, for example we could use direnv.

[teleaziz]

same as here #321 (comment)

[mandx]

How about making these module level symbols like UPPER_CASE? This can help a lot when reading code, like it's easier to see what are local vars/arguments and what is global (which should be used with care).

Suggested change

	const multibar = new cliProgress.MultiBar(
	const MULTIBAR = new cliProgress.MultiBar(

[mandx]

Maybe refactor this into it's own thing? So this could end up being just:

Suggested change

	const graphqlClient = createClient({
	fetcher: ({ query, variables }, fetch, qs) =>
	fetch(`${root}/api/v2/admin?${qs.stringify({ query, variables })}`, {
	headers: {
	'Content-Type': 'application/json',
	Authorization: `Bearer ${privateKey}`,
	},
	}).then(r => r.json()),
	});
	const graphqlClient = createBuilderGraphQLClient(privateKey);

[mandx]

Since the only thing we do here is report out the error, I suggest to not use a try-catch here, and have the caller report the problem. The caller could (optionally) pass in the progress bar / multibar instances, allowing the inner function to still report progress.

function importSpace(privateKey: string, directory: string, logger?, progressBar?) { ... }

// CLI
  // ...
  .action(options => {
    try {
       importSpace(options.key, options.output, loggerInstance, progressBarInstance);
    } catch (err) {
      console.error(`\r\n\r\n`, chalk.red('Error importing space', err));
      process.exit(1);
    }
  }); 

This simplifies the actual worker functions a lot, by them not having to worry too much about error handling and user reporting, that's the responsibility of the CLI layer.

[mandx]

While this is being used only once at the moment I would suggest to also abstract away this into a function (taking just the key and JSON body as params), so future code would just use that function, instead of copy and pasting this block.

Also keep in mind that fetch doesn't throw on non-OK HTTP statuses, we would have to check the response's statusCode and throw accordingly to signal errors during writes to this API.

[teleaziz]

Merging to get a dev version up, will address remaining feedback when I move the admin-sdk work here into it's own package.