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

Bug.

What is the current behavior?

oclif command foo:bar-baz does not report an error regarding snake-case needed for the bar-baz topic, and creates the files.

Repro:

1. Create a new plugin
2. In the root of the new plugin folder, run oclif command foo:bar-baz.

Note that the command and topic is created, even though a dash is not allowed (see below).

What is the expected behavior?

oclif command foo:bar-baz should report an error regarding snake-case needed for the bar-baz topic (and not create the files) as per the .eslintrc config.

If you created a new topic file manually with a dash in it in src/commands, eslint will complain because of the eslint rules set.

eslint error:

[eslint] Filename is not in snake case. Rename it to `bah_baz.js`. (unicorn/filename-case)

Version

oclif/1.7.50 darwin-x64 node-v8.10.0
macOS X 10.13.4

currently there isn't a great way to distribute internal oclif plugins (those not on the public npm registry). You can specify a registry for a CLI but this is global and doesn't allow the CLI end-users a way to change the registry just for themselves.

We should support adding plugins from git, tarballs, and potentially a way to use multiple registries.

the project generator by oclif single

I don't use yarn in my workflow and I'd prefer not to add it for one project. As such, I did not select yarn during the generator process yet it's referenced all over the generated build scripts and README.

Just tested oclif, really nice tool!

When trying the built-in help, I noticed that -h misses the 2nd half that's shown in --help

$ ./bin/run -h
Bolt Cypher Shell

VERSION
  boltsh/0.0.0 darwin-x64 node-v9.4.0

USAGE
  $ boltsh [COMMAND]

undefined

$ ./bin/run --help
Execute Cypher Queries via Bolt

USAGE
  $ boltsh QUERY

ARGUMENTS
  QUERY  Cypher Query to Run

OPTIONS
  -a, --address=address    (required) [default: bolt://localhost] bolt address
  -h, --help               show CLI help
  -p, --password=password  (required) user password
  -u, --user=user          (required) [default: neo4j] neo4j user
  -v, --version            show CLI version

EXAMPLE
  $ boltsh -a bolt://localhost -u neo4j -p test "MATCH (n:Person) return n.name"
  n.name
  Keanu Reeves
  Tom Hanks
  ...

Hey folks,

at first I would like to thank you to build something awesome like oclif, I like it very much!
Currently the packaging and publishing process is hard-wired and cannot be changed.

Is there a possibility to pack and create a pkg installer (tarball, win, or deb package) without the binding to AWS S3?

Thanks in advance!

Hey folks,

I've some trouble with generating a .pkg installer with the oclif-dev package. After executing the command yarn run prepack I get the following output:

❯ yarn run prepack
yarn run v0.27.5
$ rm -rf lib && tsc && oclif-dev manifest && oclif-dev readmeD
wrote manifest to /Users/xynnn/Projects/Oclif/test-cli/.oclif.manifest.json
replacing <!-- usage --> in README.md
TypeError: Cannot read property 'replace' of undefined
    at Readme.commandCode (~/Projects/Oclif/test-cli/node_modules/@oclif/dev-cli/lib/commands/readme.js:148:38)
    at Readme.renderCommand (~/Projects/Oclif/test-cli/node_modules/@oclif/dev-cli/lib/commands/readme.js:127:18)
    at commands.map.c (~/Projects/Oclif/test-cli/node_modules/@oclif/dev-cli/lib/commands/readme.js:108:39)
    at Array.map (<anonymous>)
    at Readme.commands (~/Projects/Oclif/test-cli/node_modules/@oclif/dev-cli/lib/commands/readme.js:108:25)
    at Readme.run (~/Projects/Oclif/test-cli/node_modules/@oclif/dev-cli/lib/commands/readme.js:36:112)
    at <anonymous>
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

My README.md have the necessary placeholders "toc", "usage", "commands". Anybody know to solve this issue?

Thanks in advance.

I started using oclif today and I really like it!

In my commands I use several other service classes (for talking to 3-rd party providers). I want to initialize those classes at one single point of entry. I tried doing that in the index.ts but it never gets called.

What am I missing here? Can I use the mentioned hooks. If yes, where can I find the documentation?

Or do you handle such things with a Command Base Class?

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

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

Bug, but it's more of a question since I'm not familiar with oclif's setup for nyc

What is the current behavior?

I'm attempting to build a CLI to write to the file system and need to know the current working directory and use path join operations. When I include 'path' and reference 'process' in the commands the commands work fine; however, when attempting to run tests, it does not pick up these types, fails to compile that command, and the tests for the command fail with 'command X not found' even though the command works by testing manually.

Can reproduce by:

1. npx oclif multi error-test
2. Run `npm t` to test and see passing
3. Update the hello command to use `path` or `process` and update test assertions if needed
4. Run `npm t` to test again

Example error:

(node:10600) TSError Plugin: <removed>: ⨯ Unable to compile TypeScript
src\commands\create.ts (2,23): Cannot find module 'path'. (2307)
src\commands\create.ts (26,31): Cannot find name 'process'. (2304)
...

Oddly enough, if I manually run tsc -p ./tsconfig.json to compile the commands and tsc -p /test/tsconfig.json to compile the tests they both compile fine. npm run posttest is also good. It's only when the compilation is through the npm test script that it fails to find the node types.

"dependencies": {
    "@oclif/command": "1.4.30",
    "@oclif/config": "1.6.19",
    "@oclif/plugin-help": "1.2.11",
    "tslib": "1.9.1"
  },

"typescript": "2.8.3"

I also tried manually installing @types/node as devDependency and that still didn't help.

What is the expected behavior?

I would expect that if tests compile through directly invoking tsc on their associated tscconfig project, then the npm test command similarly should succeed compilation.

Can someone help me understand where the difference is or perhaps what changes I can make to the test/tsconfig.json ?

I've tried forcing it to pick up node types by adding types: ["node"] but those should have already been included since they are in default typesRoots

you can create a new command with oclif command but it isn't mentioned in the README

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

Feature.

I really like Oclif, but ran into a blocker when trying to port an existing CLI app. In my current app, I generate commands dynamically through a for loop, like so: https://github.com/milesj/beemo/blob/master/packages/cli/src/CLI.ts#L44

With Oclif, it looks like each command needs a file, which isn't possible for my app. Is there a way to have a shared command that can be used for all these dynamic entries?

What is the current behavior?

Not supported.

What is the expected behavior?

Supports dynamic commands.

we could possibly offer an alternate tslint (with semicolons, airbnb, etc) but that can come later. For now, we should make it so tslint is only installed if desired like with mocha and typescript.

Changes needed:

• add option to disable tslint
• only add tslint.json when tslint is specified
• only add tslint to package.json when tslint is specified

To illustrate the current problem: right now it's a bit strange that you can select tslint but not typescript. Here is what I think should be the ideal flow:

• typescript? Y/n
• (if typescript) tslint? Y/n
• mocha?: Y/n
• CI (checkboxes, all default to no)
  • CircleCI
  • TravisCI
  • Appveyor
• optional components (checkboxes, all default to no)
  • codecov (only shown if mocha)
  • semantic-release

I noticed that the generated tests don't look like the mocha tests that I'm used to. That's probably because they leverage @oclif/test.

I'm not opposed to that at all (especially if it makes testing easier 😄), but it would be helpful when writing new tests to have some documentation to reference.

I plan on writing some tests, if you want I would be willing to help write up some documentation as I go

ts-node does not appear to be working—at least not after creating a brand new CLI and adding a hook to it.

Reproduction:

(With #77 merged)

$ oclif multi mycli
$ cd mycli
$ oclif hook myhook
$ ./bin/run hello
  @oclif/config loading plugins [ { root: '/Users/jdickey/src/github.com/oclif/oclif/tmp/plugin/everything/bin/run' } ] +0ms
  @oclif/config reading core plugin /Users/jdickey/src/github.com/oclif/oclif/tmp/plugin/everything +4ms
  @oclif/config using manifest from /Users/jdickey/src/github.com/oclif/oclif/tmp/plugin/everything/.oclif.manifest.json +2ms
  @oclif/config loading plugins [ '@oclif/plugin-help' ] +1ms
  @oclif/config reading dev plugin /Users/jdickey/src/github.com/oclif/oclif/tmp/plugin/everything/node_modules/@oclif/plugin-help +0ms
  @oclif/config using manifest from /Users/jdickey/src/github.com/oclif/oclif/tmp/plugin/everything/node_modules/@oclif/plugin-help/.oclif.manifest.json +1ms
  @oclif/config config done +0ms
  oclif-example init version: @oclif/[email protected] argv: [ 'hello' ] +0ms
  @oclif/config start init hook +1ms
  @oclif/config registering ts-node at /Users/jdickey/src/github.com/oclif/oclif/tmp/plugin/everything +1ms
  @oclif/config hook init /Users/jdickey/src/github.com/oclif/oclif/tmp/plugin/everything/lib/hooks/init/myhook.js +199ms
  @oclif/config done init hook +0ms
  @oclif/config runCommand hello [] +3ms
  @oclif/config require /Users/jdickey/src/github.com/oclif/oclif/tmp/plugin/everything/src/commands/hello.ts +0ms
  @oclif/config start prerun hook +1ms
  @oclif/config done prerun hook +0ms
  oclif-example:hello init version: @oclif/[email protected] argv: [] +0ms
hello world from /Users/jdickey/src/github.com/oclif/oclif/tmp/plugin/everything/src/commands/hello.ts!
(node:44048) [MODULE_NOT_FOUND] Error Plugin: everything: Cannot find module '/Users/jdickey/src/github.com/oclif/oclif/tmp/plugin/everything/lib/hooks/init/myhook.js'
module: @oclif/[email protected]
task: runHook init
plugin: everything
root: /Users/jdickey/src/github.com/oclif/oclif/tmp/plugin/everything
Error Plugin: everything: Cannot find module '/Users/jdickey/src/github.com/oclif/oclif/tmp/plugin/everything/lib/hooks/init/myhook.js'
    at Function.Module._resolveFilename (module.js:543:15)
    at Function.Module._load (module.js:470:25)
    at Module.require (module.js:593:17)
    at require (internal/module.js:11:18)
    at Promise.all.map (/Users/jdickey/src/github.com/oclif/oclif/tmp/plugin/everything/node_modules/@oclif/config/lib/config.js:107:34)
    at Array.map (<anonymous>)
    at promises.plugins.map.p (/Users/jdickey/src/github.com/oclif/oclif/tmp/plugin/everything/node_modules/@oclif/config/lib/config.js:96:18)
    at Array.map (<anonymous>)
    at Config.runHook (/Users/jdickey/src/github.com/oclif/oclif/tmp/plugin/everything/node_modules/@oclif/config/lib/config.js:94:39)
    at Main.run (/Users/jdickey/src/github.com/oclif/oclif/tmp/plugin/everything/node_modules/@oclif/command/lib/main.js:10:27)
module: @oclif/[email protected]
task: runHook init
plugin: everything
root: /Users/jdickey/src/github.com/oclif/oclif/tmp/plugin/everything

Workaround: Run tsc manually to compile the hook.

I have a commands folder which has two other folders foo and bar, which have some topics inside them. When running ./bin/run, the output lists the two possible commands, but also their description.

The thing is, when using topics I never define a description for the "top-level" command. But there is one anyway, and from what I observed it takes the first file from each commands folders and uses its description.

So, when having a foobar folder and inside the folder is a define command with description of Defines a new value, the output lists

Commands
foobar        Defines a new value

Which does not make sense, because running the foobar command itself is not possible (due to having topics), and the description is from another "topic-command"

I would like to be able to define a generic description for a top-level command.

Hey folks,

Currently I'm wondering how I can implement sub commands in oclif. I know that oclif can handle single cli and multi cli commands, but I need one more sub command layer like the following.

bin/run cli project list or
bin/run cli project create
bin/run cli project delete

How do you achieve this?

Thanks in advance!

This might be a request for an optional feature, or possibly something that can be done with a hook or plugin without needing to be in oclif directly.

I've got a cli that should be installed a dev dependency because it'll be installed in CI environments, but works best if it's installed globally (it's a swiss army knife of sorts, so it's ideal if it's on the PATH).

Ideally, a globally installed cli would check if the current project has installed a version of that cli. If so, it should delegate to the version installed in the project rather than the globally installed version. Further, this logic should be available from a folder in a given project, not just the root. Ideally, it would work in monorepos so, discovering a package.json wouldn't cause it to stop searching upward from the current directory. mycli --version should print both the local and globally installed versions (and possibly their paths).

I can see arguments both ways on whether this should be a feature of oclif. I've got a hack in place that seems to work, but I feel like it could be improved with a better understanding of how oclif loads commands. From that point of view, maybe this is really a documentation issue. On the other hand, I can see this as a pretty generic need that's hard to test, so making it a feature of oclif (or something in the @oclif namespace) might save a lot of folks a lot of trouble (or, better, by making this easy, a lot more projects might implement this behavior for free).

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

I have a command with the following args config:

static args = [{
      name: 'property',
      required: true,
      description: 'The value you want to change',
      options: [
        'FOOBAR',
        'STORE',
        'VALUE'
      ]
    }]

When executing that command in the cli with the --help flag, the description gets posted, but not the options. Only upon supplying a wrong value, the user gets information about what values he can provide.

I personally would expect the --help flag to output all necessary information about the command.

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

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

I'm pretty sure this is a bug.

What is the current behavior?

By default, a newly generated multi CLI project will fail tests. Steps to reproduce:

npx oclif multi new-project # Choose all default options
cd new-project
yarn test

The result is:

yarn run v1.6.0
warning ../../package.json: No license field
$ nyc mocha --forbid-only "test/**/*.test.ts"


  hello
--------------|----------|----------|----------|----------|-------------------|
File          |  % Stmts | % Branch |  % Funcs |  % Lines | Uncovered Line #s |
--------------|----------|----------|----------|----------|-------------------|
All files     |    91.67 |    66.67 |      100 |    91.67 |                   |
 src          |        0 |        0 |        0 |        0 |                   |
  index.ts    |        0 |        0 |        0 |        0 |                   |
 src/commands |    91.67 |    66.67 |      100 |    91.67 |                   |
  hello.ts    |    91.67 |    66.67 |      100 |    91.67 |                10 |
--------------|----------|----------|----------|----------|-------------------|
error Command failed with exit code 2.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

What is the expected behavior?

The tests should pass.

oclif version: 1.7.44
OS: Arch Linux

I would like to create a 2nd level nested command, something like:

mycli apps:list
mycli apps:builds:create
mycli apps:builds:list

The documentation provides an example of how to modify the help for the apps topic, but I also want to modify the help topic for the apps:builds topic.

I was hoping to be able to do something like this in the package.json

"topics": {
      "apps": {
        "description": "manage your apps",
        "builds": {
             "description": "manage your builds for an app"
          }
      }
    }

Also as a suggestion, would it be possible to define an index.ts file in your command subdirectories where you could specify the topic's description as opposed to modifying the package.json?

perhaps this should be a new page on best practices for building CLIs

not work。 em... Do anyone know what to do

this is just a badge in the readme but we feel better set by the app developer after creating the CLI

need to be removed from readme template and circleci

for instance, if 2 flags have the same short char

yarn build uses rm which is not available under windows

The documentation mentions the ability to run this.error and this.exit however they are undefined and not part of the ags passed into the hook function.

Looking for some help to understand how to call these functions?

https://oclif.io/docs/hooks.html

Version: oclif/1.7.30 darwin-x64 node-v9.8.0

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

it would be nice if we had a standard way that oclif users could configure their CLI. Possibly this could be linked in with rc files of some sort. This may be better as a separate package.

it's just a badge and is easy enough to add after the fact

const { args } = this.parse(MyCLI)

this.log('args', args)
// args

It looks like only the first argument will be logged. I say that because of
this:

this.log(args) 
// { 'my-arg': 'my-value' } 

What I would expect is this

this.log('args', args)
// args { 'my-arg': 'my-value' } 

To clarify, I made the assumption that this.log would behave exactly the same
as console.log. Is that the expected behavior? If so, would you like any help
implementing that?

There might be some sharp edges related to the other features of console.log,
like formatting and substitution:
https://developer.mozilla.org/en-US/docs/Web/API/console#Outputting_text_to_the_console

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

Bug

What is the current behavior?

I just created brand new cli with multi command setup such as:

npx oclif multi test01
cd test01
./bin/run hello -h

What is the expected behavior?

Windows 10 x64
Oclif:

"dependencies": {
    "@oclif/command": "^1.4.20",
    "@oclif/config": "^1.6.17",
    "@oclif/plugin-help": "^1.2.10"
  },

See error below. Notice the full --help works fine, but the shorter alias -h shows some error message.

add a hook generator like we have for commands

• create hook file
• add hook to pjson

using the not-found plugin we show friendly "did you mean" messages when a user mistypes a command. It would be nice if this also showed "did you mean" messages for mistyped flags.

Example:

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

export class extends Command {
  static flags = {
    'my-flag': flags.string()
  }

  async run() {}
}

Usage:

$ ./bin/run --myflag
Did you mean --my-flag?

This logic would probably have to go into the parser.

Right now the init hook is not being run during help/version. It should but making this work is less than trivial with how things are currently setup unfortunately.

I'd like my cli to accept e.g. --fail-fast or --failFast, but I'd like to define that as { failFast: flags.boolean() }.

I've been trying to get this to work by overriding Command#parse(), but it seems like I need to do something at a deeper level.

if building the manifest fails the CLI warns. This is fine for normal execution, but when creating the manifest with oclif-dev manifest it should exit with nonzero status. Warn is here: https://github.com/oclif/config/blob/master/src/plugin.ts#L195

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

when not in a project currently:

$ npx oclif command stars

/Users/jdickey/src/github.com/oclif/oclif/src/generators/command.ts:27
    this.pjson.oclif = this.pjson.oclif || {}
                                  ^
TypeError: Cannot read property 'oclif' of undefined
    at CommandGenerator.prompting (/Users/jdickey/src/github.com/oclif/oclif/src/generators/command.ts:27:35)
    at Object.<anonymous> (/Users/jdickey/src/github.com/oclif/oclif/node_modules/yeoman-generator/lib/index.js:399:25)
    at /Users/jdickey/src/github.com/oclif/oclif/node_modules/run-async/index.js:25:25
    at new Promise (<anonymous>)
    at /Users/jdickey/src/github.com/oclif/oclif/node_modules/run-async/index.js:24:19
    at self.env.runLoop.add.completed (/Users/jdickey/src/github.com/oclif/oclif/node_modules/yeoman-generator/lib/index.js:400:11)
    at runCallback (timers.js:763:18)
    at tryOnImmediate (timers.js:734:5)
    at processImmediate (timers.js:716:5)