oclif / command

oclif base command

oclif CLI

• oclif CLI
• 🗒 Description
• 🚀 Getting Started Tutorial
• 📌 Requirements
• 📌 Migrating from V1
• 🏗 Usage
• 📚 Examples
• 🔨 Commands
• Command Topics
• 🚀 Contributing
• 🏭 Related Repositories
• 🦔 Learn More

🗒 Description

This is the oclif CLI for the Open CLI Framework, that supports the development of oclif plugins and CLIs.

See the docs for more information.

🚀 Getting Started Tutorial

The Getting Started tutorial is a step-by-step guide to introduce you to oclif. If you have not developed anything in a command line before, this tutorial is a great place to get started.

See Usage below for an overview of the oclif CLI.

📌 Requirements

Currently, Node 18+ is supported. We support the LTS versions of Node. You can add the node package to your CLI to ensure users are running a specific version of Node.

📌 Migrating from V1

If you have been using version 1 of the oclif CLI there are some important differences to note when using the latest version.

Breaking Changes

• oclif multi, oclif plugin, and oclif single have all been removed in favor of oclif generate, which generates an oclif based CLI using the hello-world example repo.
  • The reason is that there's not enough of a meaningful difference between a "multi command cli", a "single command cli", and a "plugin" to justify the maintenance cost. The generated CLI can be easily used for any of those use cases.
• oclif hook is now oclif generate:hook
• oclif command is now oclif generate:command

New Commands

Version 2 now includes all the commands from the oclif-dev CLI. This means that you can now use a single CLI for all your oclif needs. These commands include:

• oclif manifest
• oclif pack
• oclif pack:deb
• oclif pack:macos
• oclif pack:win
• oclif upload (formerly known as oclif-dev publish)
• oclif upload:deb (formerly known as oclif-dev publish:deb)
• oclif upload:macos (formerly known as oclif-dev publish:macos)
• oclif upload:win (formerly known as oclif-dev publish:win)
• oclif readme

🏗 Usage

Creating a CLI:

$ npx oclif generate mynewcli
? npm package name (mynewcli): mynewcli
$ cd mynewcli
$ ./bin/run.js --version
mynewcli/0.0.0 darwin-x64 node-v9.5.0
$ ./bin/run.js --help
USAGE
  $ mynewcli [COMMAND]

COMMANDS
  hello
  help   display help for mynewcli

$ ./bin/run.js hello world
hello world! (./src/commands/hello/world.ts)

📚 Examples

• Hello-World
• Salesforce CLI
• Heroku CLI

🔨 Commands

Command Topics

• oclif generate - Generate a new CLI
• oclif help - Display help for oclif.
• oclif init - Initialize a new oclif CLI
• oclif manifest - Generates plugin manifest json (oclif.manifest.json).
• oclif pack - Package an oclif CLI into installable artifacts.
• oclif promote - Promote CLI builds to a S3 release channel.
• oclif readme - Adds commands to README.md in current directory.
• oclif upload - Upload installable CLI artifacts to AWS S3.

🚀 Contributing

See the contributing guide.

🏭 Related Repositories

• @oclif/core - Base library for oclif. This can be used directly without the generator.
• @oclif/test - Test helper for oclif.

🦔 Learn More

• Salesforce Release Announcement
• Heroku Release Announcement

command's Issues

@oclif/config should be a production dependency

In https://github.com/oclif/command/blob/master/src/command.ts#L51, @oclif/config is used as part of the run method. So why is it that in package.json, it's not listed as a production dependency? Is it because it's listed as such in the main oclif package here?

The current arrangement breaks monorepo projects whose dependencies are managed by pnpm because of the way each monorepo dependency's dependencies are isolated from each other. If we could move the @oclif/config dependency out of devDependencies and into dependencies, that would be 🔥 🔥 🔥 . It's also more correct since @oclif/config is being used at runtime.

PR: #60

CC: @zkochan

[Security] V1.8.0 has dependencies to vulnerable packages

NPM audit report of this project has 5 moderate severity vulnerabilities.

EPIPE error

I'm seeing this error based on a new oclif project, but it seems like the error is coming from a decision in this module so I thought I would open this here 😀

If you have a command that writes many things to stdout asynchronously, it's possible that it will throw an EPIPE error. This could happen if the output of an oclif command is piped to another command that will not wait for the first to finish. An example of this is piping to head -n 1.

Here is a minimal repo to reproduce the error: https://github.com/JuanCaicedo/oclif-piping-error

I found some references to this node error, with this perhaps being the most relevant: nodejs/node#947

I was able to fix this behavior by changing the manual use of process.stdout.write here with console.log. Is there a reason to prefer writing to stdout? Otherwise I think this might fix it. I will submit a PR

[QUESTION] How to easily add styling to `this.log`

I assume that a commands log mirrors console.log and that would mean that you can introduce styling and color. Is this correct?

Also, is it worth taking advantage of something like chalk so that users can just do: this.log('yellow', msg) or similar? Maybe this is better suited for cli-ux

Please publish release notes

Some of these changelogs have no information on the change, and it makes it really hard as a consumer to know what to expect between versions.

The base class error logger throws an error

Maybe this is a disparity in the docs or my understanding, but this.error is defined as the following:

Display error and exit. Also add a code to error object or exit status.

I wrote a couple of commands out, and was really surprised to see that this throws. So if you try to do something like the following:

try {
  const res = await myAsyncFunc();

  // Handle known error states, where the callee has more context
  if (res.error) {
    // Maybe do some logging or something around the callers context
    this.error(res.error)
  }
} catch (error) {
  this.error('Unknown error');
}

Then the CLI will print two error messages; once for the known state, and then that will throw into the unknown error state.

Is it expected that throwing is being used for the flow here? I thought this would be a "safe" exit, i.e. calling something like process.exit() under the hood.

@oclif/plugin-help should be a production dependency

Similar to #59

I have this error when using pnpm and passing --help to my CLI project:

Error: Cannot find module '@oclif/plugin-help'

My workaround for now is to declare @oclif/plugin-help as a dependency of my project.

Flush always takes 10 seconds to exit

It seems that flush should be checking the result of process.stdout.write to see if it was already flushed or not. For example

async function flush() {
    const p = new Promise(resolve => process.stdout.once('drain', () => resolve()));
    const flushed = process.stdout.write('');

    if(flushed) {
      return Promise.resolve()
    }

    return p;
  }

If it's NOT flushed, then wait for drain. Otherwise because it's already drained the event never seems to fire so the other promise.race always wins

Version 1.8.4 is a breaking change - node engine changed from >=8 to >=12

@peternhale
node engine change: 2eb9002#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519L37

This should be a major version because it breaks existing systems using older node versions, e.g. our CI/CD failed when installing packages because the node version in the image used there is node v10.

Parse method doesn't work without passing class

Base abstract child

import { Command, flags } from '@oclif/command'

abstract class AP extends Command {
  static flags = {
    help: flags.help({ char: 'h' }),
    file: flags.string({
      description: 'File path',
      required: true,
    }),
  }

  async run() {
    const { flags } = this.parse() // It should work without class name so that it can be dynamic
    console.log(flags.file)
  }
}

export default AP

Child class

import AP from '../../abstract/ap'

export default class API extends AP {
  static description = `Extended`

  static examples = [`$ my-cli api`]

  static flags = AP.flags
}

export default API

But it shows error Property 'file' does not exist on type 'unknown'.ts(2339)

An in-range update of fancy-test is breaking the build 🚨

The devDependency fancy-test was updated from 1.4.0 to 1.4.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

fancy-test is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ✅ ci/circleci: node-8: Your tests passed on CircleCI! (Details).
• ✅ ci/circleci: node-latest: Your tests passed on CircleCI! (Details).
• ❌ continuous-integration/appveyor/branch: AppVeyor build failed (Details).

---

Release Notes for v1.4.1

1.4.1 (2018-09-14)

Bug Fixes

• use generic tuples from ts3 (d89fed0)

Commits

The new version differs by 3 commits.

• 6a3c7ad chore(release): 1.4.1 [skip ci]
• d89fed0 fix: use generic tuples from ts3
• 33ae116 chore: updated lint config

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

[QUESTION] Is flag.completion type used anywhere?

Is this part of the code (just type) used anywhere?

command/src/flags.ts

Lines 6 to 22 in fb28f3e

	export type ICompletionContext = {
	args?: { [name: string]: string };
	flags?: { [name: string]: string };
	argv?: string[];
	config: IConfig;
	}
	export type ICompletion = {
	skipCache?: boolean;
	cacheDuration?: number;
	cacheKey?(ctx: ICompletionContext): Promise<string>;
	options(ctx: ICompletionContext): Promise<string[]>;
	}
	export type IOptionFlag<T> = Parser.flags.IOptionFlag<T> & {
	completion?: ICompletion;
	}

These types are defined but isn't actually used anywhere. Is that correct?

Search Reference: https://github.com/search?q=org%3Aoclif+completion&type=Code

tsc error: `PromiseLike<any> is not assignable to Promise<any>`

I was using v.1.5.0, but as soon as I upgraded to v1.5.4 or greater I see this error in my posttest script: tsc -p test --noEmit. (same result if I used the typescript package)

Error log:

node_modules/@oclif/command/lib/main.d.ts:3:22 - error TS2417: Class static side 'typeof Main' incorrectly extends base class static side 'typeof Command'.
  Types of property 'run' are incompatible.
    Type '(argv?: string[] | undefined, options?: LoadOptions) => PromiseLike<any>' is not assignable to type '(argv: string[], config?: LoadOptions) => Promise<any>'.
      Type 'PromiseLike<any>' is missing the following properties from type 'Promise<any>': catch, [Symbol.toStringTag], finally

3 export declare class Main extends Command {
                       ~~~~


Found 1 error.

Error: An accessor cannot be declared in an ambient context

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

When building a project with a Typescript version less than 3.7, build fails with an error

ERROR in ../node_modules/@oclif/command/lib/command.d.ts:48:9 - error TS1086: An accessor cannot be declared in an ambient context.

48     get ctor(): typeof Command;
           ~~~~

error Command failed with exit code 1.

This appears to be happening since v1.6.0 (Breaking change introduced in #85). Previous version of oclif v1.5 does not have this issue (as typescript is an earlier version).

What is the expected behavior?

Build should succeed. I'm not sure if typescript can be downgraded, or at least a Breaking Change be noted in the changelog, etc.

x-post: oclif/oclif#350

allow help output override via templating

See also:

• oclif/plugin-help#39
• oclif/oclif#213

Is there a way to overwrite errors?

In my CLI, if required flags are not provided, is it possible to overwrite the error function in order to prompt user to enter the flags?

Dependency tree build fails

I can no longer use and build project with following setup:

 "dependencies": {
    "@oclif/command": "^1",
    "@oclif/config": "^1",
    "@oclif/plugin-help": "^2",
    "axios": "^0.19.1",
    "cli-ux": "^5.3.3",
    "shelljs": "^0.8.3",
    "tslib": "^1"
  },
  "devDependencies": {
    "@oclif/dev-cli": "^1",
    "@oclif/test": "^1",
    "@types/chai": "^4",
    "@types/mocha": "^5",
    "@types/node": "^10",
    "chai": "^4",
    "eslint": "^5.13",
    "eslint-config-oclif": "^3.1",
    "eslint-config-oclif-typescript": "^0.1",
    "globby": "^10",
    "mocha": "^5",
    "nyc": "^14",
    "ts-node": "^8",
    "typescript": "^3.3"

it fails with 404 on yarn registry for oclif command

sfpowerkit plugin Install failed Accenture/sfpowerkit

Hi Team,

The installation of the latest version of the library seems to be causing memory leak issues.
Everything was working fine until a few hours ago.
It seems to coincide with the release of the version 1.8.12.

warning "sfpowerkit > @salesforce/command > @oclif/[email protected]" has unmet peer dependency "@oclif/config@^1".

Could you please have a look?

Help output does not show subcommands when invoked via -h

Given a multi-command CLI with the following structure:

bin/
    run
src/
    commands/
        toplevel/
            index.js
            subcommand.js
    index.js

Running ./bin/run toplevel --help will display the subcommand in the help message:

COMMANDS
  toplevel:subcommand  Describe the command here

However, running ./bin/run toplevel -h does not display the subcommand in its help message. The section is omitted.

This appears to be because the help message is displayed via two separate code paths; running the command with --help calls into Main#_help() and using -h calls into Command#_help(). Why are there two methods that do different things for command help?

404 Not Found: @oclif/[email protected]

Whenever I try to execute npm install, I am getting 404 Not Found for the @oclif/command package. Below given is an extract of the error log

4105 verbose type Error
4106 verbose stack Error: 404 Not Found: @oclif/[email protected]
4106 verbose stack     at fetch.then.res (/Users/foo/.nvm/versions/node/v8.9.0/lib/node_modules/npm/node_modules/pacote/lib/fetchers/registry/fetch.js:42:19)
4106 verbose stack     at tryCatcher (/Users/foo/.nvm/versions/node/v8.9.0/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23)
4106 verbose stack     at Promise._settlePromiseFromHandler (/Users/foo/.nvm/versions/node/v8.9.0/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:512:31)
4106 verbose stack     at Promise._settlePromise (/Users/foo/.nvm/versions/node/v8.9.0/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:569:18)
4106 verbose stack     at Promise._settlePromise0 (/Users/foo/.nvm/versions/node/v8.9.0/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:614:10)
4106 verbose stack     at Promise._settlePromises (/Users/foo/.nvm/versions/node/v8.9.0/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:693:18)
4106 verbose stack     at Async._drainQueue (/Users/foo/.nvm/versions/node/v8.9.0/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:133:16)
4106 verbose stack     at Async._drainQueues (/Users/foo/.nvm/versions/node/v8.9.0/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:143:10)
4106 verbose stack     at Immediate.Async.drainQueues (/Users/foo/.nvm/versions/node/v8.9.0/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:17:14)
4106 verbose stack     at runCallback (timers.js:789:20)
4106 verbose stack     at tryOnImmediate (timers.js:751:5)
4106 verbose stack     at processImmediate [as _immediateCallback] (timers.js:722:5)
...
4108 verbose Darwin 19.0.0
4109 verbose argv "/Users/foo/.nvm/versions/node/v8.9.0/bin/node" "/Users/foo/.nvm/versions/node/v8.9.0/bin/npm" "install"
4110 verbose node v8.9.0
4111 verbose npm  v5.5.1
4112 error code E404
4113 error 404 Not Found: @oclif/[email protected]

Thanks in Advance

_swallowEPIPE can cause an event emitter leak

So this call to _swallowEPIPE is going to cause an event emitter leaks if you run multiple oclif commands in the same node process. Our test framework is just plagued with these warning messages. I even see it in some custom plugins.

(node:74128) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 error listeners added. Use emitter.setMaxListeners() to increase limit

I think you can make _swallowEPIPE static and then ensure the event listener is installed only once. It seems to fix the warning in my test and will satisfy the intended use case.

something like....

/**
* swallows stdout epipe errors
* this occurs when stdout closes such as when piping to head
*/
static _swallowEPIPE() {
if (!this.installedStdoutErrorListener) {
process.stdout.on('error', err => {
if (err && err.code === 'EPIPE')
return;
throw err;
});
this.installedStdoutErrorListener = true;
}
}

@elbandito @RasPhilCo FYI

The short hand help flag '-h' doesnt work if strict is set to `false`

When extending the BaseCommand and setting strict = false the CLI is not recognizing -h the same way it recognizes the --help flag.

Issues seems to be in the method at https://github.com/oclif/command/blob/master/src/command.ts#L203 where its only accounting for --help.

Disable ansi

Thanks for this nice tool :)

I have test snapshots in jest running locally that have ansi but on CI do not, thus causing the snapshots to fail there but not on my machine. I resorted to using strip-ansi but would prefer a simple way to disable ansi. I tried the docs of chalk for doing so here but did not seem to work.

Anyways, as a user, I would ideally be finding docs about this in oclif, only going to other tools' docs if explicitly directed to do so.

Async flag options?

Is it possible to hydrate a list of options in the flags from an async function? A good use case would be to dynamically detect the input options for an array.

Enum flags do not work with multiple

The enum flag with multiple does not work.

When creating an enum flag with multiple options, they are not properly processed due to the build not returning an array over here:

https://github.com/oclif/command/blob/master/src/flags.ts#L53

MaxListenersExceededWarning: Possible EventEmitter memory leak detected

I've recently been hitting this error when running tests for our Oclif CLI:

(node:29441) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 error listeners added. Use emitter.setMaxListeners() to increase limit
    at _addListener (events.js:280:19)
    at WriteStream.addListener (events.js:297:10)
    at WriteStream.Readable.on (_stream_readable.js:772:35)
    at Snapshot._swallowEPIPE (/Users/djones/Code/percy-agent/node_modules/@oclif/command/lib/command.js:133:24)
    at Snapshot.init (/Users/djones/Code/percy-agent/node_modules/@oclif/command/lib/command.js:67:14)
    at Snapshot._run (/Users/djones/Code/percy-agent/node_modules/@oclif/command/lib/command.js:33:24)
    at Function.Command.run (/Users/djones/Code/percy-agent/node_modules/@oclif/command/lib/command.js:155:16)
    at <anonymous>

After a wee bit of googling I noticed the Heroku CLI has actually been getting the same warnings recently: https://ci.appveyor.com/project/heroku/heroku-cli-command/branch/master#L174

and I found this for the Force.com CLI: forcedotcom/cli#30

Fairly sure it was #54 that has introduced this bug, so I downgraded to @oclif/command 1.5.10 (from 1.5.12) and it has fixed the issue.

I think the problem is that here:

protected _swallowEPIPE() {
  process.stdout.on('error', err => {
    if (err && err.code === 'EPIPE') return
    throw err
  })
}

we turn on process.stdout.on but it is never closed so the listeners pile up.

The automated release is failing 🚨

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

---

The push permission to the Git repository is required.

semantic-release cannot push the version tag to the branch master on remote Git repository.

Please refer to the authentication configuration documentation to configure the Git credentials on your CI environment.

---

Good luck with your project ✨

Your semantic-release bot 📦🚀

The automated release is failing 🚨

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

---

Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two-Factor Authentication, make configure the auth-only level is supported. semantic-release cannot publish with the default auth-and-writes level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.

---

Good luck with your project ✨

Your semantic-release bot 📦🚀

Command seems to implicitly include the help plugin

This seems to rely on the help plugin, which rather defeats the object of a plugin; it also makes it non-trivial to write your own help command.

strongly-typed args

EDIT FROM JEFF: despite what this says, we already support strongly-typed flags, but with typescript 3.x I think it would also be possible to support args

As of now, when I try to lookup what values are present on args and flags, it's quite tricky and it's not accurate because of any typing. If we could make it generic something like this:

import {Command, flags} from '@oclif/command'

interface IFlags {
  help: IBooleanFlag
  name: string
  connected: boolean
}
interface IArgs {
  file: string
}

export default class ReactComponent extends Command<IFlags, IArgs> {
  static description = 'Generate react components'

  static flags = {
    help: flags.help({char: 'h'}),
    name: flags.string({char: 'n', description: 'Component Name'}),
    connected: flags.boolean({char: 'c', description: 'add connect()'})
  }
  static args = [{name: 'file'}]
  async run() {
    const {args, flags} = this.parse(ReactComponent)
    const name = flags.name || 'world'
  }
}

I do realize that doing argument parsing is different than it is now, that could be tackled either with next major version with breaking changes, or we can find a way around that (or simply say parse will return that type). This would improve experience by so much.

1.8.12 -> memory leak

Hi there,

The installation of the latest version of the library seems to be causing memory leak issues.
Everything was working fine until a few hours ago.
It seems to coincide with the release of the version 1.8.12.

warning "sfpowerkit > @salesforce/command > @oclif/[email protected]" has unmet peer dependency "@oclif/config@^1".

Could you please have a look?

An in-range update of @types/node is breaking the build 🚨

The devDependency @types/node was updated from 10.10.0 to 10.10.1.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

• ✅ ci/circleci: node-latest: Your tests passed on CircleCI! (Details).
• ✅ ci/circleci: node-8: Your tests passed on CircleCI! (Details).
• ✅ continuous-integration/appveyor/branch: AppVeyor build succeeded (Details).
• ✅ codecov/project: No report found to compare against (Details).
• ✅ codecov/patch: Coverage not affected. (Details).
• ❌ Build: We could not find a valid build file. Please ensure that your repo contains a cloudbuild or a Dockerfile.

---

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Your Greenkeeper Bot 🌴

@oclif/command/flush is not typed

The @oclif/command/flush module is not typed, as it seems to be just a js file in the project root.

When working with a TypeScript codebase, this doesn't work well.

Stable whitespace rendering

I am seeing unstable snapshot results for stdout text between macOS a linux machine on CircleCI.

build

Is it possible that this is related to oclif somehow? Not sure, the issue could be at numerous different levels.

    - Snapshot
    + Received

      Object {
        "status": 0,
        "stderr": "",
    -   "stdout": "USAGE
    +   "stdout": "USAGE
        $ nexus typegen [ENTRYPOINT]
      
    - ARGUMENTS
    + ARGUMENTS
        ENTRYPOINT
    -       
    -       Relative path (from cwd) to your app's TypeScript module that will run 
    -       directly or indirectly Nexus.makeSchema. By default the following paths will 
    -       be searched, picking the first match, or erroring out
    -       
    -           * src/schema/index.ts
    -           * src/schema.ts
    -           * src/server.ts
    -           * src/main.ts
    -           * src/index.ts
    -       
    -           * schema/index.ts
    -           * schema.ts
    -           * server.ts
    -           * main.ts
    -           * index.ts
    -       
    -             ERROR
    +       Relative path (from cwd) to your app's TypeScript module that will run 
    +       directly or indirectly Nexus.makeSchema. By default the following paths will 
    +       be searched, picking the first match, or erroring out
    + 
    +            * src/schema/index.ts
    +            * src/schema.ts
    +            * src/server.ts
    +            * src/main.ts
    +            * src/index.ts
      
    - DESCRIPTION
    +            * schema/index.ts
    +            * schema.ts
    +            * server.ts
    +            * main.ts
    +            * index.ts
    + 
    +              ERROR