Add new command and CLI packages

[cevr]

Hello!

I wanted to add something that I thought would be useful to this project.

It adds the new command, detailed in the changes to the readme.

It also added three new packages

• yargs : added to make parsing arguments a little easier for the new command, since there are a lot of flags
• inquirer: added to include some prompting to make the flow easier
• find-up: added to be able to quickly find the project base-path

Finally, it added the bundle option to build command. Primarily so we only have to include one file for the cli, but also because globs do not work on windows.

Some other stuff I want to add is testing eventually haha

Let me know if any of this is a no go, doesn't make sense, or is unwanted.

Thank you 😄

[kiliman]

Thanks for the PR. I'm not seeing the README changes you mentioned.

Anyway, this looks like a great feature. I like the addition of yargs. It was my intention to make the cli part be a shell for custom commands.

Instead of having to update the cli every time a new command is added, I think the command itself should export the config, then the cli just has to pass that along to yarg for parsing.

Eventually I'd like to make it so new commands can be added as external packages. When you type rmx command, it will first look to see if that command is in the commands folder, or will look to see if there's a package rmx-cli-commandname and import that.

This way people can publish new commands without having to worry about parsing and dynamic loading, etc.

[cevr]

Sorry about that! Forgot to push 😆

[cevr]

@kiliman In regards to this PR, are you suggesting that the changes made are incompatible with the vision you have? If so, let me know and I'll close it

If not, are there any changes you would like to be done?

[kiliman]

I like your changes... but I would like to move the command specific yargs to the command itself instead of the cli.

So in each command, export a function that returns the yargs config (without the handler part)

// commands/eject-ras.ts
export function config() {
  return yargs.command(
    'eject-ras',
    'Eject your Remix project from Remix App Server to Express',
  )
}
// commands/get-esm-packages.ts
export function config() {
  return yargs.command(
    'get-esm-packages <packages..>',
    'Scan for ESM package to add to remix.config.js serverDependenciesToBundle',
    yargs => {
      return yargs.positional('packages', {
        desc: 'Packages to scan for ESM dependencies',
        default: [] as string[],
        array: true,
      })
    }
  )
}
etc... 

Then in the cli, we import command.config(), execute that with the arguments, and if successful, will execute command.default and pass in the yargs result.

This way, we can add new commands without having to update cli.ts.

And in the future, will be able to add new commands with a simple npm package name rmx-cli-command-name.

Does that make sense? So if you can refactor your command this way, that would be awesome. If you don't have the time, then we can merge what you have and I'll make the changes.

Thanks!

[cevr]

just added some ground work for the plugins.

Basically what I imagined was something like this:

• when a user adds a command with something like rmx add <command>, this will get stored into our internal cli conf store with everything we need to execute the command later
• then everytime we access our conf on startup, it will have access to all the remote commands added by the user

The advantages of this approach I suppose would be discoverability with something like rmx --help, as it would then include any remote commands you've installed. Thats if this approach even works

Some concerns I suppose are QC - how to we ensure quality of plugins? Bad actors? Not much can be done since node is so permissive

The other approach I think would be maybe just adding a command like rmx execute <remote command> [args...] which has the advantage of being much easier but no discoverability if done before. We could mitigate this by storing parameters every plugin the user has used in our conf and just refer to that on startup and just show them that when they do rmx --help

[kiliman]

I figure commands that are added by the user are either done via file system path (so local commands) or npm install -g (install to global). The onus is on the user to verify.

Perhaps if command not recognized, it can check npm for rmx-cli-<command-name> and offer to install it.

As for help, rmx --help should list commands already known, and rmx command --help should display the yargs help for that command.

Anyway, thanks for working on this. I think it'll be nice to have an easy way to add scripts to manage remix projects. Having one cli rmx makes it easier to remember than having to remember a bunch of different scripts.

Also, one other thing... need to look at how to incorporate command autocomplete for https://fig.io/

[cevr]

We could also use the common rmx-cli.config.js or something, and have a field called commands: [] which people can just import their installed commands to and call.

Something like

import customCommand from 'rmx-cli-custom-command'

module.exports = {
  commands: [customCommand()]
}```

then in the cli we can just import the config file and concat it to our list of commands