oclif / config

base config object and standard interfaces for oclif components

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

config's Issues

Spurious warning for missing "files" in package.json

config/src/plugin.ts

Line 109 in aedf35e

if (!this.pjson.files) this.warn(`files attribute must be specified in ${pjsonPath}`)

There may be a good reason for this warning but it appears to me to be spurious, or at least in the wrong place, given that:

• There is a documented default value (["*"]).
• Omitting it shows the warning, but nothing breaks when using a command.

I can see this was done intentionally but there's no extra context I can find to explain why.

Config runCommand should return result

I'm not sure if this was the intended behavior or not, but I noticed recently while working with SFDX and TypeScript that the result of commands bubbles nearly all the way up to the caller - only to be abandoned here. I'm guessing that the intent was for the caller to implement postRun to get explicit access to the result, but not all commands do, leaving result to dangle at the penultimate moment.

For my current use-case (scanner:run), I can get around this issue because that command itself can actually write to the filesystem, but it'd be vastly preferable to avoid the extra fs work (and open up the flexibility of other commands' being more easily interacted with at the TypeScript-level).

allow JSX and TSX commands

currently the command discovery rule here:

config/src/plugin.ts

Line 155 in d84a238

'**/*.+(js|ts)',

only matches .js and .ts files. However, .tsx files are also valid typescript. As react-ink becomes a thing, we should enable that too.

Maybe just add another regex for *x files? happy to PR this if y'all like it

An in-range update of debug is breaking the build 🚨

Version 3.2.0 of debug was just published.

Branch	Build failing 🚨
Dependency	debug
Current Version	3.1.0
Type	dependency

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

debug is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details

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

---

Release Notes

3.2.0

A long-awaited release to debug is available now: 3.2.0.

Due to the delay in release and the number of changes made (including bumping dependencies in order to mitigate vulnerabilities), it is highly recommended maintainers update to the latest package version and test thoroughly.

---

Minor Changes

• bump vulnerable packages: 853853f
• Fix nwjs support (#569): 207a6a2
• add instance extends feature (#524): e43e5fe
• Add TVMLKit support (#579): 02b9ea9

Patches

• move to XO (closes #397): ba8a424
• clean up builds: 3ca2331
• remove needless command aliases in makefile: 9f4f8f5
• no longer checking for BROWSER=1: 623c08e
• fix tests: 57cde56
• clean up makefile: 62822f1
• fix tests: 833b6f8
• add .editorconfig: 2d2509e
• add yarn-error.log to .gitignore: 7e1d5d9
• add Node.js 10, remove Node.js 4 (#583): 05b0ceb
• Improve usability of Windows notes w/ examples for prompts & npm script (#577): 1ad1e4a
• Drop usage of chrome.storage (or make the storage backend pluggable): 71d2aa7
• Detect 'process' package: 225c66f
• Update ms to 2.1.1 (#539): 22f9932
• Update .npmignore (#527): a5ca7a2
• fix colors with supports-color@5: 285dfe1
• Document enable() (#517): ab5083f
• refactor to make the common code be a setup function (#507): 7116906
• Simplify and improve: da51af8

Credits

Huge thanks to @DanielRuf, @EirikBirkeland, @KyleStay, @Qix-, @abenhamdine, @alexey-pelykh, @DiegoRBaquero, @febbraro, @kwolfy, and @TooTallNate for their help!

Commits

The new version differs by 25 commits.

• dec4b15 3.2.0
• 3ca2331 clean up builds
• 9f4f8f5 remove needless command aliases in makefile
• 623c08e no longer checking for BROWSER=1
• 57cde56 fix tests
• 62822f1 clean up makefile
• 833b6f8 fix tests
• ba8a424 move to XO (closes #397)
• 2d2509e add .editorconfig
• 853853f bump vulnerable packages
• 7e1d5d9 add yarn-error.log to .gitignore
• e43e5fe add instance extends feature (#524)
• 207a6a2 Fix nwjs support (#569)
• 05b0ceb add Node.js 10, remove Node.js 4 (#583)
• 02b9ea9 Add TVMLKit support (#579)

There are 25 commits in total.

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 🌴

config breaks jest inline snapshots due to ts-node/register

import HelloWorld from '@src/commands/hello_world';

describe('fmt', () => {
  it('writes the results to disk', async () => {
    try {
      await HelloWorld.run([]);
    } catch (e) {
      console.log(e);
    }

    expect({}).toMatchInlineSnapshot();
  });
});

The above will fail in a typescript project due to config setting up tsNode.register. This is because Jest sees there's already a transformer for TypeScript, and so doesn't apply its own transformer.

This is "fine", except that the output of ts-node doesn't match the output of Babel (which is what jest uses); when writing inline snapshots, jest looks for all toMatchInlineSnapshot matchers by walking the ast as provided by Babel.

As such, it fails to find the snapshot matcher because while Babel is walking the AST, it didn't do the transformation, so the line numbers are different and it never finds the matcher.

In general, @oclif/config probably shouldn't be using ts-node like this, as it's not really needed: it's encouraging users to ship TS files when they should be compiled, and this behaviour can be replicated in userland by calling tsNode.register in your bin script, or by passing it to node as part of the call (for when testing, which I assume is why this feature was added).

Additionally, it's probably going to cause oclif some pain when ESM modules land, as it'll likely force people to stick on commonjs.

Removing ts-node would solve a number of issues that have been opened around oclif packages.

Cannot read property 'filter' of undefined

I got the error from the title.
It is in lib/config.js:90:83

Introduced in the following commit
a23329a

if (!pjson.oclif) pjson.oclif = {schema: 1}
await this.loadPlugins(userPJSONPath, 'user', pjson.oclif.plugins.filter((p: any) => p.type === 'user'))

you set pjson.oclif to { schema: 1 }
and then tries to call filter on its property plugins which is undefined

S3 Templates not found as mentioned in the docs

I was reading the docs and I was reading about the part about auto-updater in releasing section. It mentions that there are s3 templates that allow us to set url to any host that serves files in the dist folder built by oclif-dev pack command. But I don't see any templates here. Am I missing something here?
For reference it is written here

WSL for config.platform

Is it feasible to include the Windows subsystem for Linux (WSL) as an additional literal in PlatformTypes and resolve the platform property in the config using the is-wsl module as was done in your cli-ux repo? WSL is currently resolving to Linux which is causing a strange edge case for some of our users.

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 📦🚀

tsconfig "extends" not used

Thanks for this project! It's been really useful to me. One thing I noticed is that it looks like the tsconfig.json is parsed here:

config/src/ts-node.ts

Lines 37 to 40 in 25ea412

	const tsconfig = typescript.parseConfigFileTextToJson(
	tsconfigPath,
	fs.readFileSync(tsconfigPath, 'utf8'),
	).config

and used in a few places, including here:

config/src/ts-node.ts

Lines 73 to 77 in 25ea412

	compilerOptions: {
	esModuleInterop: tsconfig.compilerOptions.esModuleInterop,
	target: tsconfig.compilerOptions.target || 'es2017',
	experimentalDecorators: tsconfig.compilerOptions.experimentalDecorators || false,
	emitDecoratorMetadata: tsconfig.compilerOptions.emitDecoratorMetadata || false,

However, if you have your oclif tsconfig.json extend another tsconfig.json (e.g. in a monorepo setup) like this:

tsconfig.json

{
  "compilerOptions": {
    "target": "es2016",
    "esModuleInterop": true,
  },
}

packages/my-oclif-project/tsconfig.json

{
  "extends": "../../tsconfig.json",
  "compilerOptions": {
    "declaration": true,
    "importHelpers": true,
    "module": "commonjs",
    "outDir": "lib",
    "rootDir": "src",
    "strict": true,
    "noEmit": false,
  },
  "include": ["src"],
}

the "extends" is never followed, so the tsconfig does not inherit e.g. "target" and "esModuleInterop" from the base config. (About extending base configs: https://www.typescriptlang.org/docs/handbook/tsconfig-json.html#tsconfig-bases)

Topics subtopics are not respected without a name

Repo:
Given the following topics list in the oclif package.json:

"topics": {
      "t1": {
        "description": "desc for t1",
        "subtopics": {
          "t1-1": {
            "description": "desc for t1-1",
            "subtopics": {
              "t1-1-1": {
                "description": "desc for t1-1-1"
              },
              "t1-1-2": {
                "description": "desc for t1-1-2"
              }
            }
          }
        }
      }
    }
  },

Then run ./bin/run t1 --help.

Expected results:

USAGE
  $ bin t1:COMMAND

COMMANDS
  t1:t1-1  desc for t1-1

Actual results:

USAGE
  $ bin t1:COMMAND

COMMANDS
  t1:t1-1  desc for the first command in t1-1

Potential Fix
I debugged this a little big and narrowed it down to this line: https://github.com/oclif/config/blob/master/src/plugin.ts#L249

Specifically ${base}${input[k].name}. It seems like what you want here is actually ``${base}${k}` since you are still dealing with the object, but not sure the original intent. The code looks like it wants a name property in the subtopic property but that seems counter-intuitive since I'm using a map. If I make the change locally, everything works fine, but I'm not sure if I am breaking another case.

If I have time, I'll try to create a PR.

Getting "Cannot find module 'ts-node'" when running with DEBUG=*

ts-node is in devDependencies of @oclif/config however if I run CLI with DEBUG=* I see the following:

@oclif/config Error: Cannot find module 'ts-node'
  @oclif/config Require stack:
  @oclif/config - /Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/ts-node.js
  @oclif/config - /Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/plugin.js
  @oclif/config - /Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/config.js
  @oclif/config - /Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/index.js
  @oclif/config - /Users/arodik/projects/ffbt/node_modules/@oclif/command/lib/command.js
  @oclif/config - /Users/arodik/projects/ffbt/node_modules/@oclif/command/lib/index.js
  @oclif/config - /Users/arodik/projects/ffbt/dist/cli/entrypoint.js
  @oclif/config     at Function.Module._resolveFilename (internal/modules/cjs/loader.js:794:15)
  @oclif/config     at Function.resolve (internal/modules/cjs/helpers.js:80:19)
  @oclif/config     at registerTSNode (/Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/ts-node.js:19:32)
  @oclif/config     at Object.tsPath (/Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/ts-node.js:77:9)
  @oclif/config     at Plugin.get commandsDir [as commandsDir] (/Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/plugin.js:68:42)
  @oclif/config     at Plugin.get commandIDs [as commandIDs] (/Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/plugin.js:70:19)
  @oclif/config     at Plugin._manifest (/Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/plugin.js:161:28)
  @oclif/config     at async Plugin.load (/Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/plugin.js:56:25)
  @oclif/config     at async Config.load (/Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/config.js:28:9)
  @oclif/config     at async Object.load (/Users/arodik/projects/ffbt/node_modules/@oclif/config/lib/config.js:334:5) +1ms

We don't use ts-node because we don't need it
Our package.json

Pass command args to `command_not_found` hook

Relates to twilio/twilio-cli#190

Requesting command args be passed with the command string when invoking command_not_found hook:

config/src/config.ts

Line 352 in 954ed2c

await this.runHook('command_not_found', {id})

(node:83072) SyntaxError Plugin: stocli: Unexpected token import

When running oclif, I get the following error:

(node:83072) SyntaxError Plugin: stocli: Unexpected token import
module: @oclif/[email protected]
task: toCached
plugin: stocli

I have the latest versions installed.

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 📦🚀

Pull Request: Native ES Module support for Oclif w/ continued support of CommonJS

Greets,

I have to say I have been enjoying working with Oclif. It is going to allow me to complete a complex CLI project soon. What would be even better is being able to work with ES Modules (ESM) for the core CLI and plugin development. I personally along with folks like Sindre Sorhus are moving to ESM for all new Node releases imminently. Tooling needs to play catchup, but I like Oclif so much I spent a full day updating Oclif to support ESM along with maintaining CommonJS support. With my pull request it is possible to write core Oclif CLI code with ESM along with loading a mixture of ESM / CJS Oclif plugins. As noted at the bottom of the pull request I put up a separate Github repo w/ the compiled Typescript code that can be linked from Github to replace @oclif/config enabling ESM support now.

I look forward to working on this pull request and getting things on the up and up for Oclif w/ ESM support.

Apologies for the double issue post here and in @oclif issues. I just figure posting there as well might reach a few more eyes in general.

v1.12.2 causes cli issues

I am not using the typescript option. Things worked fine in v1.12.0.

> ./bin/run

module.js:550
    throw err;
    ^

Error: Cannot find module 'typescript'
    at Function.Module._resolveFilename (module.js:548:15)
    at Function.Module._load (module.js:475:25)
    at Module.require (module.js:597:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/Users/xxx/sourcecode/service/node_modules/@oclif/config/lib/ts-node.js:5:22)
    at Module._compile (module.js:653:30)
    at Object.Module._extensions..js (module.js:664:10)
    at Module.load (module.js:566:32)
    at tryModuleLoad (module.js:506:12)
    at Function.Module._load (module.js:498:3)

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 🌴

Identify which plugin command belongs to

From the context of a running command, there is no populated property indicating which plugin the command belongs to. We have BaseCommand which has utilities used both by the CLI and plugins. I'd like it to be able to identify the plugin name/config in order to create a separate directory for placing assets so that plugins don't have conflicts when accessing these files.

@oclif/errors should be a dependency

See this line:

import {CLIError, error, exit, warn} from '@oclif/errors'

@oclif/errors must be declared as a dependency, not a devDependency. The only reason you aren't getting bitten by this (mostly) is because the current implementation of npm and yarn are shamelessly flattening the package hierarchy, thus hiding missing dependency declarations.

Remove transpileOnly flag in dev (or make optional)

https://github.com/oclif/config/blame/a3e3052c4acfece3acd66bab5a13ba7a32f7f6f9/src/ts-node.ts#L42

This means that typechecking doesn't happen during development, which obviously I can see the arguments for, in that it's gonna allow for faster iteration, but personally I'd prefer the command to just fail and force my team to fix their types. I don't know if that's a minority opinion, but if so I would appreciate this at least being somehow optional, perhaps by setting some field in package.json, given that that's read from anyway?

Support for .oclifrc/.oclifrc.json/.oclifrc.js

It looks like the only way to provide the configuration data is through package.json https://github.com/oclif/config/blob/master/src/config.ts#L293

Can we add support for having an rc file?

Getting "module not found 'typescript' when running with DEBUG=*

  @oclif/config Cannot find typescript { Error: Cannot find module 'typescript'
    at Function.Module._resolveFilename (module.js:548:15)
    at Function.Module._load (module.js:475:25)
    at Module.require (module.js:597:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (/Users/daghassi/git/cli/node_modules/@oclif/config/lib/ts-node.js:9:18)
    at Module._compile (module.js:653:30)
    at Object.Module._extensions..js (module.js:664:10)
    at Module.load (module.js:566:32)
    at tryModuleLoad (module.js:506:12)
    at Function.Module._load (module.js:498:3) code: 'MODULE_NOT_FOUND' } +0ms

I assume this is an easy fix as right now typescript is a dev dependency in this repo, and it needs to be a dependency since this relies on it directly.

An in-range update of ts-node is breaking the build 🚨

Version 6.1.0 of ts-node was just published.

Branch	Build failing 🚨
Dependency	ts-node
Current Version	6.0.5
Type	devDependency

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

ts-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-8 Your tests failed on CircleCI Details
• ✅ ci/circleci: node-latest Your tests passed on CircleCI! Details
• ✅ continuous-integration/appveyor/branch AppVeyor build succeeded Details

---

Release Notes

TypeScript Error Formatting

Changed

• Use TypeScript error formatting for diagnostic ouput
• Delete declarationMap option from input configuration under ts-node

Commits

The new version differs by 5 commits.

• ee5c1b3 6.1.0
• 57f09b5 Remove declarationMap from config (#602)
• 70d68ef Document -T alias in README (#600)
• 6c610b4 Use NODE=stable tag over specific version (#598)
• 2e44bc0 Use ts.formatDiagnostics over of custom function (#597)

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 🌴

Incompatible with yarn2 and PnP

The root property is calculated assuming the folder structure with node_modules

config/src/plugin.ts

Line 109 in 71fb6d9

async function findRoot(name: string | undefined, root: string) {

a project attempting to use Yarn Plug'n'Play fails to load with

could not find package.json with

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 📦🚀

question: why are all commands loaded up front?

config/src/plugin.ts

Line 170 in e0b5e95

this._debug('require', p)

I can see that for my companies CLI, we are requiring all 13 commands up front. Does this make sense/is it necessary? The CLI has the command I want when I pass in a command. What is the need for requiring all the other commands if I'm not going to use them? In our case, this is adding almost 3s to initial startup time.

An in-range update of ts-node is breaking the build 🚨

Version 6.0.4 of ts-node was just published.

Branch	Build failing 🚨
Dependency	ts-node
Current Version	6.0.3
Type	devDependency

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

ts-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 failed on CircleCI Details
• ❌ ci/circleci: node-8 Your tests failed on CircleCI Details
• ❌ continuous-integration/appveyor/branch AppVeyor build failed Details

---

Release Notes

Windows Project Resolution

Fixed

• Normalize paths for Windows before trying to resolve the project path
• Use Buffer.from instead of deprecated new Buffer

Commits

The new version differs by 3 commits.

• 98d72ce 6.0.4
• 4f40026 Use Buffer.from
• 45664e7 Fix project path resolution on Windows (#596)

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 🌴

Fails silently if (.)oclif.manifest.json is missing

There is a bug in src/plugin.ts:readManifest()
If both oclif.manifest.json and .oclif.manifest.json are missing, the exception is caught and mistakenly silenced.

The nesting level of the this.warn line might be wrong. No warning is issued if the .oclif.manifest.json is missing too.

Possible fix?
if (!dotfile) return readManifest(true) else this.warn(error, 'readManifest').

      } catch (error) {
        if (error.code === 'ENOENT') { // both exceptions are caught here
          if (!dotfile) return readManifest(true) // PROBLEM IS HERE
        } else {
          this.warn(error, 'readManifest')
        }
      }

The cli project throws Cannot find module 'globby' error

The CLI projects throws Cannot find module 'globby' error. Here's the error I'm getting when I simply run a command:

$ ./bin/run hello

(node:23379) [MODULE_NOT_FOUND] Error Plugin: my-test-cli: Cannot find module 'globby'
module: @oclif/[email protected]
task: not loading commands, globby not found
plugin: my-test-cli
root: /home/kabir/opensource/my-test-cli
See more details with DEBUG=*
Error Plugin: my-test-cli: Cannot find module 'globby'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
    at Function.resolve (internal/modules/cjs/helpers.js:33:19)
    at Plugin.get commandIDs [as commandIDs] (/home/kabir/opensource/my-test-cli/node_modules/@oclif/config/lib/plugin.js:64:40)
    at Plugin._manifest (/home/kabir/opensource/my-test-cli/node_modules/@oclif/config/lib/plugin.js:151:28)
module: @oclif/[email protected]
task: not loading commands, globby not found
plugin: my-test-cli
root: /home/kabir/opensource/my-test-cli

This happened after I cleaned up my package.json file to contain only @oclif/* and my core dependencies.

Here's my question - is this package globby required to function any oclif based CLI application? If yes, then should it not be in oclif's dependencies list? I didn't find it there.

config/package.json

Lines 7 to 12 in b0c2c9e

	"dependencies": {
	"@oclif/errors": "^1.0.0",
	"@oclif/parser": "^3.8.0",
	"debug": "^4.1.1",
	"tslib": "^1.9.3"
	},

This means the user always needs to install globby in their CLI, or else it won't work.
Please suggest if this was intentional or is an issue. If it is, then I guess moving this from your devDependencies to dependencies would solve it for us.

Thanks!

We seem to be getting an error when the cli attempt to update plugins.

We seem to be getting a new error in the cli that seems to be related to this change:

e0b5e95

We are seeing cases in the sfdx-cli when parent.children is undefined and this
results in the following error:

Installing dependencies for /Volumes/CaseAware/force-com-toolbelt... ⢿
(node:70974) TypeError Plugin: cli-engine: Cannot read property 'push' of undefined
module: @oclif/[email protected]
task: loadPlugins
plugin: cli-engine
root: /Users/tnoonan/tmp/node_modules/cli-engine
See more details with DEBUG=*
(node:70974) TypeError Plugin: cli-engine: Cannot read property 'push' of undefined
module: @oclif/[email protected]
task: loadPlugins
plugin: cli-engine
root: /Users/tnoonan/tmp/node_modules/cli-engine

Steps:

1. Completely remove sfdx from the system:

sudo rm -rf /usr/local/sfdx
sudo rm -rf /usr/local/lib/sfdx
sudo rm -rf /usr/local/bin/sfdx
sudo rm -rf ~/.local/share/sfdx ~/.config/sfdx ~/.cache/sfdx
sudo rm -rf ~/Library/Caches/sfdx

2. Install sfdx

npm install sfdx-cli

3. Install a plugin
   node_modules/sfdx-cli/bin/run plugins:install salesforcedx@pre-release

This results in the error above.

use semantic release or similar to publish release notes

This is minor, but as someone who consumes this repo I get PRs via renovate that can surface the changelog from an incoming release. Would it be possible to have this repo create release notes so I can better understand what happens between versions?

Command name (options.id) is undefined in a hook

We had a problem in this hook which is the same as the example, where options.id was undefined.

console.log(options.id); // returns undefined
console.log((options as any).Command.id); // returns command name

At first I thought that it could be a problem because I ran it on the init hook, but the official example is pretty much this.

Did I use it wrong?, Are the TS annotations wrong?

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 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 📦🚀

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

• ❌ continuous-integration/appveyor/branch: Waiting for AppVeyor build to complete (Details).
• ❌ ci/circleci: node-8: Your tests failed on CircleCI (Details).
• ✅ ci/circleci: node-latest: Your tests passed on CircleCI! (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 🌴

An in-range update of ts-node is breaking the build 🚨

Version 6.2.0 of ts-node was just published.

Branch	Build failing 🚨
Dependency	[ts-node](https://github.com/TypeStrong/ts-node)
Current Version	6.1.2
Type	devDependency

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

ts-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-8 Your tests failed on CircleCI Details
• ✅ ci/circleci: node-latest Your tests passed on CircleCI! Details
• ✅ continuous-integration/appveyor/branch AppVeyor build succeeded Details

---

Release Notes

Files Config Flag

Added

• New flag (--files) can be used to disable loading files from tsconfig.json by default

Commits

The new version differs by 2 commits.

• f260591 6.2.0
• 14c7e26 Add flag to skip loading files from 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 🌴

@oclif/parser should be a production dependency

Similar to oclif/command#59

Right now, I need to specify @oclif/parser as a dependency of my CLI project, otherwise I encounter this error:

../../common/temp/node_modules/.registry.npmjs.org/@oclif/config/1.13.0/node_modules/@oclif/config/lib/command.d.ts:1:25 - error TS2307: Cannot find module '@oclif/parser'.

1 import * as Parser from '@oclif/parser';
                          ~~~~~~~~~~~~~~~

Since the typedef of @oclif/config depends on @oclif/parser, it should really be a production dependency.

An in-range update of lodash is breaking the build 🚨

The devDependency lodash was updated from 4.17.10 to 4.17.11.

🚨 View failing branch.

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

lodash 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 failed on CircleCI (Details).
• ❌ ci/circleci: node-latest: Your tests failed on CircleCI (Details).
• ❌ continuous-integration/appveyor/branch: AppVeyor build failed (Details).

---

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 🌴

Array flag reading other flags

when an array flag is used with a default, but the user doesn't specify a value, subsequent flags are read into the array

suggestion: array flags don't read values starting with - or --

An in-range update of ts-node is breaking the build 🚨

Version 6.0.5 of ts-node was just published.

Branch	Build failing 🚨
Dependency	ts-node
Current Version	6.0.4
Type	devDependency

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

ts-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-8 Your tests failed on CircleCI Details
• ✅ ci/circleci: node-latest Your tests passed on CircleCI! Details
• ✅ continuous-integration/appveyor/branch AppVeyor build succeeded Details

---

Release Notes

Normalize More Places For Windows

Fixed

• More places to normalize for Windows to work

Commits

The new version differs by 2 commits.

• e2e3eaf 6.0.5
• 33aca82 Normalize configFileName on initialization

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 🌴

Finding plugins breaks when the package manager doesn't use node_modules

When trying to use oclif with a package manager such as Yarn 2, the following error message occurs:

(node:621147) Error Plugin: @maintainer/package: could not find package.json with {
  type: 'core',
  root: '/path/to/project/root',
  name: '@oclif/plugin-help'
}
module: @oclif/[email protected]
task: loadPlugins
plugin: @maintainer/package
root: /path/to/project/root
See more details with DEBUG=*

Digging into the code, it seems pretty obvious that this is because of the fact that this package looks for plugins in node_modules, but Yarn 2 doesn't use node_modules.

config/src/plugin.ts

Lines 109 to 135 in 07a0670

	async function findRoot(name: string | undefined, root: string) {
	// essentially just "cd .."
	function * up(from: string) {
	while (path.dirname(from) !== from) {
	yield from
	from = path.dirname(from)
	}
	yield from
	}
	for (const next of up(root)) {
	let cur
	if (name) {
	cur = path.join(next, 'node_modules', name, 'package.json')
	// eslint-disable-next-line no-await-in-loop
	if (await exists(cur)) return path.dirname(cur)
	try {
	// eslint-disable-next-line no-await-in-loop
	const pkg = await loadJSON(path.join(next, 'package.json'))
	if (pkg.name === name) return next
	} catch { }
	} else {
	cur = path.join(next, 'package.json')
	// eslint-disable-next-line no-await-in-loop
	if (await exists(cur)) return path.dirname(cur)
	}
	}
	}

As per the Yarn 2 documentation, this is somewhat easily solved with a change to utilize resolve@>=1.9. Any pitfalls or caveats existing contributors/maintainers can think of?

Yes, Yarn 2 is in RC stage but it will not be so eventually and this issue will need to be resolved. (Heh.)

I'm most probably going to try to fix this myself so I can obstinately use the new modules system, but tracking issues is important so I'm doing this first.