EPIC: Pattern Lab Node CLI

[bmuenzenmeyer]

Methods

• build
• patterns only
• serve
• export
• help (with commander)
• init_project
• list_starterkits
• load_starterkit
• pack_starterkit
• enable_plugin
• disable_plugin

Goals

• no grunt or gulp dependencies (is this related? I think so if you want build to work)
• globally installed
• Determine merits of core vs new repo. Goal is to not have a major breaking change to core... editions can change in any way.

Approach

Slowly convert patternlab-node to be runnable with no grunt or gulp dependencies.

[raphaelokon]

I would say: Have the bin in this repo to avoid fragmentation. This pattern is used by a lot of Node packages.

I am doing my CLI work here: https://github.com/raphaelokon/patternlab-node

[raphaelokon]

#Additional args

-c, --config    Specify config file. Default looks in root dir.

[gael-boyenval]

+1.
I think this is the cleaner option.

Proposing then a simple gulp/grunt/etc.. plugin that allow user to integrate PL commands to any workflow would be great.

[raphaelokon]

Aye. In my implementation the new CLI is the layer between those plugins and the patternlab-node core.

[bmuenzenmeyer]

Eager to see and review 👍

[raphaelokon]

Sure. It is by far not complete … and just a straw man. I am annotating a bit and will push it. Currently it is only capable of letting you specify a config path and using its build method.
I also added a test atom to the current source/ so that you can see it actually builds it into public/:)

[raphaelokon]

Okay … I pushed my initial stuff.

λ ~: node bin/patternlab.js --help //=> View Usage info
λ ~: node bin/patternlab.js build //=> Build stuff and copy from ./source -> ./public using root dir config
λ ~: node bin/patternlab.js build --config ./other/path/patternlab-config.json //=> Build stuff and copy from ./source -> ./public using specified config

[raphaelokon]

Current CLI methods implementation status:

• build (implemented as patternlab build)
• patterns only (implemented as patternlab build --patterns-only)
• serve
• export
• help/usage information
• init
• list_starterkits (implemented as patternlab list-starterkits) (Will implement Pattern Lab Node Core 2.5.1 #465)
• load_starterkit
• pack_starterkit

Note: Please note that all commands come with an alias to accommodate for personal preferences/conciseness of the commands

[gael-boyenval]

@raphaelokon do you know https://github.com/SBoudrias/Inquirer.js/ ?

Propose options during the cli process, very useful for any init phase.

• list selectors
• inputs
• check lists
• y/n inputs

i integrated it into a little cli tool that i builded as a try, and they works very nice together (with commander)

[raphaelokon]

Aye, used in some projects … already on my list for list-starterkits so that you can pick and automatically install a kit #463 . There is a nice bridge between commander and inquirer – https://www.npmjs.com/package/inquander

[raphaelokon]

@bmuenzenmeyer

Can we clarify those methods:

• serve => I am assuming we run a local server (browsersync) in the public dir?
• export => What does this mean?
• init_project => What does this mean?
• pack_starterkit => This is currently not implemented in the patternlab core. How to go about it?

[bmuenzenmeyer]

serve => I am assuming we run a local server (browsersync) in the public dir?

BrowserSync, like edition-node-gulp does. If this dependency is too great perhaps someday we strip it out to the simplest possible thing that can serve public/ and let consumers choose something more sophisticated if they want

export => What does this mean?

Similar to this existing configuration but I'd like to confirm it works like documented at http://patternlab.io/docs/advanced-exporting-patterns.html if it doesnt. I've created an issue to investigate this.

init_project => What does this mean?

This doesn't exist yet, but I envision something as described here: #281
This should be a separate implementation issue too.

pack_starterkit => This is currently not implemented in the patternlab core. How to go about it?

This is an idea I've had similar to loadstarterkit, except in reverse. This would take your entire source/ dir and zip it up into the format expected by a starterkit (really they are so damn close perhaps this wouldn't get much use). But I envision product companies having base pattern starterkits, and it'd be nice to have a way for them to work on one and then get it into the starterkit format quickly for distribution.
For now you may probably ignore this completely.

[raphaelokon]

By the time of your reply serve was already implemented and is up … :-)

I will stub pack_starterkit for now as this requires direct implementation on the core and is separate from the CLI. Those tasks probe

init and export makes pretty much sense.

Also: We need to remove the existing CLI from core … it makes absolutely no sense to have it in there with the new CLI being separated out. patternlab core should only expose a concise API.

[bmuenzenmeyer]

By the time of your reply serve was already implemented and is up … :-)

lol I sorta figured

Also: We need to remove the existing CLI from core … it makes absolutely no sense to have it in there with the new CLI being separated out. patternlab core should only expose a concise API.

Point to a commit that does this once you push it. My chief concern (if it even makes sense) is making the transition from the current edition-node-* gulpfile tasks to the new cli method calls as painless as possible. I told you all edition code is okay to change, but I'd still like to reduce change as much as possible. Don't know if I am making sense.