Packages could extend the meteor CLI

[raix]

@mquandalle made a very important pull request at meteor/meteor#2718 - I think we need to keep track of this one...

The documentation defines Meteor as two things: a library of packages that aims to provide features to your app, and a command-line tool to build one (or several) app(s) for different targets. Although it's not yet a public thing, there is also the concept of a “plugin” which is a package that extends the command-line tool. Currently the only plugin method is

Plugin.registerSourceHandler(extension, [options], handler)

This is used by packages like coffeescript, spacebars, less, stylus, harmony, etc. to auto-compile some specific files and add them to the bundle. This PR introduces a new plugin method:

Plugin.registerCommand(name, [options], action)

As the method name says, this method allows packages to register new command-line operations. It will be useful for test systems (velocity), code-generator/scaffolding tools (em), wrapped database administration, etc.

For instance the em package could register:

Plugin.registerCommand("em init", function () { /* do something */ });

And then a user could simply:

$ meteor add eventedmind:em
$ meteor em init

The exposed API is similar to what is used internally for meteor core commands, and thus allows the same level of features (sub-commands, options...).

EDIT:
Status set Community agree due to the interest from several package writers and MDG agree + Discussion due to: meteor/meteor#2718 (comment)

[PEM--]

👍

Opening the CLI to the packaging is a key components to prove that Meteor could be used instead of Gulp, Grunt, Yeoman, Webpack, Brew ... Devs accustomed to asset optimization will not go to Meteor for this reason.

[awatson1978]

+1
As part of the Velocity project, I'm quite keen to do the following:

Plugin.registerCommand("nightwatch", function () { /* run nightwatch from the command line */ });

So people can do:

meteor nightwatch
meteor nightwatch -t tests/my_walkthrough.js

[MaazAli]

Are there any updates on this? We can finally achieve rails like migrations with this addition :)

[ccorcos]

I'm a huge fan of this idea. I want to create a package that uses PhantomJS or SlimerJS to generate icons and splash screens at the appropriate sizes.

Any idea what the progress is on this?

[ccorcos]

This demo is exactly what I want to integrate into the meteor command line tool:

https://github.com/ccorcos/meteor-icon-splash-maker

[reohjs]

+1 Would love to see this implemented! A much more natural way to run functions/methods instead of using the shell IMO.

[steve8708]

Major +1

Would really love this as well. I'm writing a linting package that lints files on change but I would love to run a lint from a simple lint from a CLI command as well (or for use with CI servers like travis - esp. given that we can't add source handlers on top of existing handled extensions so we can't have lint steps currently as part of the actual build process for js, html, css, etc)

Additionally I have a mini CLI file for some commands, e.g. so I can ./cli install chalk to automatically grab the latest version of a npm package and add it to packages.json (for use with meteorhacks/npm) but I would love it if that package could register meteor npminstall chalk and meteor npmuninstall chalk

[queso]

Would love to see this. I hate that velocity has to submit to core and wait for changes to come out.

[raix]

@steve8708 https://github.com/raix/Meteor-jshint - its a bit old and hanging due to lack of this feature

[steve8708]

Yeah it's really unfortunate we can't use that package right now :(

I've been googling for a while and have seen the discussion go all over the place regarding mutiple handlers per source for build packages and I've seen you @raix and @mquandalle talking about it for quite some time in several places like meteor/meteor#1207 and #51 :)

Would REALLY love to have that as part of the real build process and a real extended CLI system - but for now I'll just have to work around these limitations

For the build issue I've had to copy what velocity does for file watching and build it into the server which is far from elegant and because it isn't part of a real build would never integrate with a CI server

I've got html, js, and coffee linting so far and also scss file injection (i.e. for auto generating @includes based on glob patterns such as client/styles/**)

[raix]

we use semaphore for hint - and in sublime or whatever using something like: https://github.com/raix/Meteor-jshintrc

[ccorcos]

Not sure where we should keep this going. I opened up a similar feature request here for hooks like CLI.onStart, CLI.onStop, and CLI.onReset which would be nice for integrating with other databases. But Plugin.registerCommand seems like a good one as well. It seems to me that this shouldn't be too hard to integrate...

[rbabayoff]

How about, similar to what atmosphere did before meteor officially supported their packaging api and created their package server, have the community create a release track for meteor that includes the Plugin.registerCommand PR, and every time meteor publishes a new release this release track get's updated. Then, you can just run your commands using:

meteor --release [email protected] mycommand

If @mquandalle is willing to update and maintain his PR going forward, I'll be happy to develop the support to easily publish a new release in the release track, every time a new meteor version is out. I've already blogged about it (here)[http://practicalmeteor.com/using-meteor-publish-release-to-extend-the-meteor-command-line-tool/], but, @mquandalle approach of extending the cli is much better, and more easily extensible, using packages. Yet, this article shows that you can actually use meteor itself to easily publish different tracks ("versions") of meteor that others can easily use.

[nscarcella]

Is there any update on this? I really liked @mquandalle proposal and would love to have this feature.

[mquandalle]

AFAIK there isn’t any update in the direction of CLI plugins.