Giter VIP home page Giter VIP logo

findhelp's Introduction

findhelp

A simple and hackable lib to help create modular command line programs.

For those times when you just need to find some help to structure your CLI. ๐Ÿ”Ž โ„น๏ธ

What

Given a tree of commands and an arguments vector, findhelp can:

  • Create a pretty "help" menu.
  • Traverse the tree and find the correct command.
  • (Optionally) Run the command handler with given args and options.

For example, this tree generates this help content:

Usage: findhelp <command> [options]

Commands:

  login <store> [email]    Login with your account
  logout                   Logout from current account
  list [query]             List your packages
  install <app>            Install the given app
  uninstall <app>          Remove the given app
  publish <app>            Publish this app

  workspace new <name>       Create a new workspace
  workspace delete <name>    Delete this workspace
  workspace promote <name>   Promote this workspace to master
  workspace list             List available workspaces

Options:

  --verbose  show all logs
  -h, --help  show help information
  -v, --version  show version number

What's interesting is that you can assemble that tree any way you want, so your commands might be handled by completely different modules - no problem.

For a real-life usage example, take a look at VTEX Toolbelt.

Why

Node has some pretty good, full-feature CLI libs, like commander, yargs and neodoc. Why write another one?

First, those projects are very opinionated. This is excellent for small and quick projects - they got the 95% of the cases covered. You won't go wrong with any of them!

However, the structure comes at the price of control. They tend to own the entire lifecycle of your CLI, which might be bad if you want fine-grained control over how your program behaves.

Second, I had a free weekend. ๐Ÿ™ƒ

How

Unlike other CLI solutions available, findhelp won't actually do anything for you. It finds the command based on arguments, and gets out of your way.

find(tree, argv) and run(command, root)

Here's a minimal example of the find usage:

#!/usr/bin/env node
import {find, run, MissingRequiredArgsError, CommandNotFoundError} from 'findhelp'
import {tree} from './fixtures' // Your tree defining the commands

try {
  const found = find(tree, process.argv.slice(2))
  run(found) // This will run the command called by the user
} catch (e) {
  switch (e.constructor) {
    case MissingRequiredArgsError:
      console.error('Missing required arguments:', e.message)
      break
    case CommandNotFoundError:
      console.error('Command not found:', process.argv.slice(2))
      break
    default:
      console.error('Something exploded :(')
      console.error(e, e.stack)
  }
}

That's it. You pass to find your command tree and your argv, and it will return an object like:

{
    command: <the Object with a handler function that matches>,
    args: ['any', 'required', 'or', 'optional', 'args', argv]
}

The last argument is always argv, as parsed by minimist. It will contain any flag options defined by your command.

You can optionally use run, which calls command.handler with the provided args for you.

help(tree, {name})

You can use that same tree to output a pretty help menu. The second parameter is an object with the name of the command line application. Here's the handler for the root command in that example:

import {help} from 'findhelp'

handler: (options) => {
  if (options.h || options.help) {
    console.log(help(tree, {name: 'findhelp'}))
  } else if (options.v || options.version) {
    console.log(pkg.version)
  } else {
    console.log('Hi, there! :)')
  }
}

No automatic anything. You're in control. (Use your power wisely).

The command tree

A command tree is composed of one or many command objects with:

  • requiredArgs: Required arguments to run the command
  • optinalArgs: Optional arguments
  • description: Description to be displayed in the help() function
  • handler: Function that will be called with the run() function passing the required and optional arguments as parameters
  • alias: An alias for the command
  • options: An object of options

The handler can be either a function or a string that locates the module where the handling function is the default export. The root parameter in run() will be used to resolve the full path of the module in the case a string is passed. If handler is not specified, findhelp will try to locate the module following the folders maching the command tree structure from the specified root (see the examples below).

Examples

login: {
  requiredArgs: 'store',
  optionalArgs: 'email',
  description: 'Login with your account',
  handler: (store, email, options) => { /* do awesome stuff! */ },
logout: {
  description: 'Logout from current account',
  handler: './logout'
},
workspace: {
  new: {
    requiredArgs: 'name',
    description: 'Create a new workspace',
    // will look at './workspace/new' (from root) for handling function
  },
  delete: {
    requiredArgs: 'name',
    description: 'Delete this workspace',
    options: [
      {
        short: 'a',
        long: 'account',
        type: 'string',
      },
    ],
    // will look at './workspace/delete' (from root) for handling function
  },
}

Here is how './workspace/delete' could look like:

export default async (name, {account}) => {
  // ...
}

These will define the following commands:

  • yourapp login <store> [email]
  • yourapp crazy <mustbegiven> [thisisfine]

Namespaces

Namespaces enable commands with 2 or more levels. Example:

workspace: {
  new: {
    requiredArgs: 'name',
    description: 'Create a new workspace',
    handler: console.log.bind(console),
  },
  delete: {
    requiredArgs: 'name',
    description: 'Delete this workspace',
    options: [
      {
        short: 'a',
        long: 'account',
        type: 'string',
      },
    ],
    handler: console.log.bind(console),
  },
}

These will define the following commands:

  • yourapp workspace new <name>
  • yourapp workspace delete <name>

Options

An array containing options:

options: [
  {
    long: 'verbose',
    description: 'show all logs',
    type: 'boolean',
  },
  {
    short: 'h',
    long: 'help',
    description: 'show help information',
    type: 'boolean',
  },
  {
    long: 'version',
    short: 'v',
    description: 'show version number',
    type: 'boolean',
  },
]

These will enable the following options:

  • yourapp --verbose

  • yourapp --help or yourapp -h

  • yourapp --version or yourapp -v

That's it

Now you know everything. Go play! Then, submit a sweet pull request to make this shinier. Thanks. ๐Ÿค“

findhelp's People

Contributors

guifromrio avatar klzns avatar rdumont avatar samuelmtimbo avatar tamorim avatar vcalasans avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Forkers

ghas-results

findhelp's Issues

Excessive use of maps

From doing the PR #3 and dealing a little bit with the library, I perceived one core problem, which is the use of maps everywhere. Maps, as we know, shouldn't have any order for their keys and values. That made me do a bit of a hack to get the namespace command represented before all others, and I believe more problems may arise from it.

So here I suggest that we switch from a map-based structure to arrays, switching from:

const tree = {
  list: {
    description: 'List apps',
    handler: () => {}
  },
  settings: {
    description: 'Get settings',
    handler: () => {},

    set: {
      description: 'Set settings value',
      handler: () => {}
    },
    unset: {
      description: 'Unset settings value',
      handler: () => {}
    }
  }
}

To:

const tree = [
  {
    name: 'list',
    description: 'List apps',
    handler: () => {}
  },
  {
    name: 'settings',
    description: 'Get settings',
    handler: () => {},
    children: [
      {
        name: 'set',
        description: 'Set settings value',
        handler: () => {}
      },
      {
        name: 'unset',
        description: 'Unset settings value',
        handler: () => {}
      },
    ]
  }
]

Yes, I know it is not as pretty, but I think it is clearer, of easier maintenance and less error-prone. For instance, ambiguity between a field and a command name would never be an issue.

@firstdoit, @tamorim, what do you think?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.