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

Bug

What is the current behavior?

Whenever I run a command on CLI built using oclif, I get the following error:

(node:8716) [MODULE_NOT_FOUND] Error Plugin: mycli: Cannot find module 'globby'
module: @oclif/[email protected]
task: not loading commands, globby not found
plugin: mycli
root: /Users/sumbhavsethia/.nvm/versions/node/v8.11.1/lib/node_modules/mycli
See more details with DEBUG=*

Installing globby globally resolves the issue

What is the expected behavior?

I should not have to install globby globally to be able to run the CLI. It should be installed as a dependency of oclif

More information

Node version: 8.11.1 oclif version: 1.4.33

package.json:

"dependencies": {
    "@oclif/command": "^1.4.33",
    "@oclif/config": "^1.6.33",
    "@oclif/plugin-help": "^1.2.11",
    "bluebird": "^3.5.1",
    "bluebird-retry": "^0.11.0",
    "chalk": "^2.3.2",
    "command-exists": "^1.2.2",
    "execa": "^0.10.0",
    "hostile": "^1.3.1",
    "inquirer": "^5.2.0",
    "inquirer-path": "^1.0.0-beta5",
    "joi": "^13.1.2",
    "latest-version": "^3.1.0",
    "lodash": "^4.17.5",
    "ora": "^2.0.0",
    "pg": "^7.4.1",
    "portscanner": "^2.1.1",
    "request": "^2.85.0",
    "request-promise": "^4.2.2",
    "semver": "^5.5.0",
    "ssh-config": "^1.1.3",
    "sshpk": "^1.14.1",
    "sudo-prompt": "^8.2.0",
    "table": "^4.0.3",
    "tmp-promise": "^1.0.4",
    "wait-port": "^0.2.2"
},
"oclif": {
    "commands": "./src/commands",
    "bin": "mybin",
    "plugins": [
      "@oclif/plugin-help"
    ],
    "topics": {
      "atopic": {
        "description": "Manages atopic"
      }
    }
},

Hi, we're building a CLI on oclif and first let me thank you for it: it's an awesome project and I wish we knew about it earlier :) Really great stuff!

One thing that's important for us is to have space-separated subcommands ("topics") like many other CLIs, e.g., git, npm, wp, docker, kubectl, gcloud, ... I was a bit surprised that oclif doesn't support them and then found this FAQ:

Short answer is that space-separated will never be supported. Longer answer is it's not possible with the way we support topics and arguments.

The major issue has to do with topic-commands. In oclif, we support topics as commands such as heroku config. There are other commands underneath heroku config like heroku config:get. If we used space separated arguments, this could be heroku config and heroku config get. However if heroku config also expected an argument, there would be no way for the command parser to tell whether or not the second argument is a command or an argument.

Some CLIs don't support topic-commands which is how this is possible for those.

We also feel that using colon-separated arguments is better CLI UX anyways. It helps the user know which arguments are the command and which are arguments to that command. It helps them find what they need in the help more directly.

Is there any way you would reconsider? CLIs with space-separated subcommands are common, not causing any issues in practice & oclif is an awesome CLI framework that could support this pattern. If you agree, we could explore how to support it and contribute the functionality back.

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

Feature

What is the current behavior?

pkg . doesnt include multi commands

What is the expected behavior?

pkg . includes multi commands

adding the following seems pretty low bar to get basic support to package.json "pkg": { "scripts": "src/commands/**/*.js" }

and "scripts: { "pkg": "pkg ." }

The docs where missing a links mutli intro introduction page to package.json:pkg.topics as the place to document the subdirectories as they are created.

Version 1.0.0 of @anycli/config was just published.

The version 1.0.0 is not covered by your current version range.

If you don’t accept this pull request, your project will work just like it did before. However, you might be missing out on a bunch of new features, fixes and/or performance improvements from the dependency update.

It might be worth looking into these changes and trying to get this project onto the latest version of @anycli/config.

If you have a solid test suite and good coverage, a passing build is a strong indicator that you can take advantage of these changes directly by merging the proposed change into your project. If the build fails or you don’t have such unconditional trust in your tests, this branch is a great starting point for you to work on the update.

Your Greenkeeper bot :palm_tree:

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

More of a confirmation that what I'm trying to do isn't supported.

What is the current behavior?

I have a command that takes an argument but also has a flag that takes multiple values. However, it doesn't look like the combination is supported, unless I'm missing something. If my flag takes multiple values, it doesn't know when to stop parsing the flag values and when to start parsing arguments. For example if I setup my command like so

static args = [{name: "file", required: true}];
static flags = {
  mod: flags.string({
    char: 'm',
    multiple: true
  })
};

Then there isn't a way to provide values for the -m flag as well as an argument because parsing the -m flag doesn't know when to stop parsing flag arguments and when to start parsing command arguments. For example, command -m one two file.txt would end in an error because it won't see any arguments to the command and creates a flags.mod array of ["one", "two", "file.txt"].

What is the expected behavior?

It seems like the only way to really support this would be some way to configure oclif to allow flags to be specified multiple times, but only with one value per flag. In my above example it would be something like command -m one -m two file.txt. Is there anyway to setup a command like that currently?

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

I want to be able to write negation tests, something that executes a command that fails argument/flag validation and then use stderr (or stdout) as part of the test to ensure my argument/flag definitions are as expected. This could be me not doing things right, or not finding the right documentation, but I don't see this in any documentation or the examples.

What is the current behavior?

Unfortunately, any type of negation test (not passing a required argument) does not populate stderr or stdout and I end up with something like this when using expect(ctx.stderr):

AssertionError: expected '' to include '...'

Here is an example:

// ...
  test.stderr()
    .command(['validate'])
    .exit(2)
    .it('require LOCATION argument', ctx => {
      expect(ctx.stderr).to.contain('Error: Missing 1 required arg:')
      expect(ctx.stderr).to.contain('location  The path/URL to the OAS document being validated')
      expect(ctx.stderr).to.contain('See more help with --help')
    })
// ...

What is the expected behavior?

I would expect that any invocation of my command would populate stdout and/or stderr, even the ones that go down the error path. (This seems to happen for missing required arguments and too many arguments.)

I'd like to request a feature.

What is the current behavior?

When you run ./bin/run you automatically get a help menu.

What is the expected behavior?

I'd like to assign functionality to that base menu when a command is not run. Basically I'd like to assign a default command that runs.

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.

I want to work on the project to create linter of oclif project under gsoc 2019 Please help me getting started with good first issue so that i get the project workflow. Also please do mention communication channel so that i can further discuss my ideas and learn from the team.

Report a bug?

What is the current behavior?

Published some updates on my package on npm and it is full broken. Steps to reproduce:

• yarn global add vestigo
• vestigo scan --target="https://127.0.0.1/" --method="GET" -w

Results in:

Error: Cannot find module '/Users/xxx/.config/yarn/global/node_modules/vestigo/lib/commands/scan'
Require stack:
- /Users/xxx/.config/yarn/global/node_modules/@oclif/config/lib/plugin.js
- /Users/xxx/.config/yarn/global/node_modules/@oclif/config/lib/config.js
- /Users/xxx/.config/yarn/global/node_modules/@oclif/config/lib/index.js
- /Users/xxx/.config/yarn/global/node_modules/@oclif/command/lib/command.js
- /Users/xxx/.config/yarn/global/node_modules/@oclif/command/lib/index.js
- /Users/xxx/.config/yarn/global/node_modules/vestigo/bin/run
    at fetch (~/.config/yarn/global/node_modules/@oclif/config/lib/plugin.js:166:31)
    at Plugin.findCommand (~/.config/yarn/global/node_modules/@oclif/config/lib/plugin.js:184:21)
    at Object.load (~/.config/yarn/global/node_modules/@oclif/config/lib/plugin.js:113:72)
    at Config.runCommand (~/.config/yarn/global/node_modules/@oclif/config/lib/config.js:170:27)
    at Main.run (~/.config/yarn/global/node_modules/@oclif/command/lib/main.js:22:27)
    at Main._run (~/.config/yarn/global/node_modules/@oclif/command/lib/command.js:43:31)

This does not happen with prior versions:

• yarn global add [email protected]
• vestigo scan --target="https://127.0.0.1/" --method="GET"

This does not happen while debugging:

• bin/run scan --target="https://127.0.0.1/" --method="GET" --report="HTML" -w

no issues

What is the expected behavior?

The command line is supposed to run like in prior versions

package.json

{
  "name": "vestigo",
  "description": "A tool for exploring and investigating APIs.",
  "version": "0.1.6",
  "author": "Mederic Burlet",
  "bin": {
    "vestigo": "./bin/run"
  },
  "bugs": "https://github.com/crimson-med/vestigo/issues",
  "dependencies": {
    "@oclif/command": "^1.6.1",
    "@oclif/config": "^1",
    "@oclif/plugin-help": "^2",
    "@types/chalk": "^2.2.0",
    "axios": "^0.19.2",
    "chalk": "^3.0.0",
    "crimson-progressbar": "^1.3.0",
    "tslib": "^1",
    "whois-json": "^2.0.4"
  },
  "devDependencies": {
    "@oclif/dev-cli": "^1",
    "@oclif/test": "^1",
    "@types/chai": "^4",
    "@types/mocha": "^5",
    "@types/node": "^10",
    "chai": "^4",
    "globby": "^10",
    "mocha": "^7.1.2",
    "nyc": "^14",
    "ts-node": "^8",
    "typescript": "^3.3"
  },
  "engines": {
    "node": ">=8.0.0"
  },
  "files": [
    "/bin",
    "/lib",
    "/npm-shrinkwrap.json",
    "/oclif.manifest.json"
  ],
  "homepage": "https://github.com/crimson-med/vestigo",
  "keywords": [
    "oclif"
  ],
  "license": "GNU GPLv3",
  "main": "lib/index.js",
  "oclif": {
    "commands": "./lib/commands",
    "bin": "vestigo",
    "plugins": [
      "@oclif/plugin-help"
    ]
  },
  "repository": "crimson-med/vestigo",
  "scripts": {
    "postpack": "rm -f oclif.manifest.json",
    "prepack": "rm -rf lib && tsc -b && oclif-dev manifest && oclif-dev readme",
    "test": "nyc --extension .ts mocha --forbid-only \"test/**/*.test.ts\" --full-trace",
    "version": "oclif-dev readme && git add README.md"
  },
  "types": "lib/index.d.ts",
  "resolutions": {
    "whois-json/whois/optimist/minimist": "^1.2.5"
  }
}

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

Report a bug

What is the current behavior?

I can't create a base class that parses flags and a derived command that parses arguments

What is the expected behavior?

I expect to be able to do this.

  "@oclif/command": "^1",
  "@oclif/config": "^1",
  "@oclif/plugin-help": "^2",
  "tslib": "^1"

I started a project with npx oclif multi mynewcli with typescript enabled. Then I created a base class:

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

export default abstract class Base extends Command {
  static flags = {
    verbose: flags.boolean()
  }

  print(message: string) {
    const { flags } = this.parse(Base)
    if (flags.verbose) {
      this.log(message)
    }
  }
}

Then I created a command that uses this base class:

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

import Base from '../base';

export default class Hello extends Base {
  static args = [{name: 'message'}]

  async run() {
    const {args} = this.parse(Hello)

    this.print(args.message)
  }
}

After that, I ran yarn prepack and then I did ./bin/run hello --verbose foo and I got this error:

 ›   Error: Unexpected argument: foo
 ›   See more help with --help

It seems like oclif thinks --verbose is the argument, and gets confused after that.

Bumps aws-sdk from 2.1231.0 to 2.1286.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps @oclif/core from 1.20.4 to 1.23.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Fixes https://github.com/oclif/oclif/issues/759

Closed https://github.com/oclif/oclif/pull/989 and updated this branch to support the deprecation of qq introduced in https://github.com/oclif/oclif/pull/1035.

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

Report a bug

What is the current behavior?

When cmd oclif pack:macos is called, it fails at pkgbuild step.

What is the expected behavior?

The package should have built successfully.

Please mention your oclif and OS version. oclif : v2 OS: macos-11 (Github Actions env)

Steps to reproduce:

1. oclif pack:macos

Error:

oclif: gathering workspace for twilio to <path>
oclif: will build 2 targets in parallel
oclif: building target twilio-v5.0.0-aaaaaa-darwin-x64.tar.gz
oclif: copying workspace ./tmp/twilio ./tmp/darwin-x64/twilio
oclif: building target twilio-v5.0.0-aaaaaa-darwin-arm64.tar.gz
oclif: copying workspace ./tmp/twilio ./tmp/darwin-arm64/twilio
oclif: downloading node-v16.19.0-darwin-x64
oclif: downloading node-v16.19.0-darwin-arm64
oclif: extracting node-v16.19.0-darwin-arm64
oclif: extracting node-v16.19.0-darwin-x64
    Error: Command failed: pkgbuild  --root 
    <root_location>
    --component-plist 
    abc.plist 
    --identifier <twilio_identifier> --version 5.0.0 --install-location 
    /usr/local/lib/twilio-cli --scripts 
    <script_location> --sign 
    twilio-x.x.x.pkg
    Usage: pkgbuild [options] --root <root-path> [--component-plist 
    <plist-path>] <package-output-path>
    	Build a package from an xcodebuild destination root

    Usage: pkgbuild --analyze --root <root-path> <plist-output-path>
    	Create template component plist from an xcodebuild destination root

    Usage: pkgbuild [options] {--component <component-path>} 
    <package-output-path>
    	Build a package from one or more previously-built bundles

    See pkgbuild(1) for details.


    Code: 1
Error: Process completed with exit code 1.

    at ChildProcess.exithandler (node:child_process:399:12)
    at ChildProcess.emit (node:events:520:28)
    at maybeClose (node:internal/child_process:1092:16)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:302:5)

Bumps minimist from 1.2.5 to 1.2.7.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps @oclif/plugin-not-found from 2.3.7 to 2.3.11.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.