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 :+1:

[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:

• [x] build (implemented as patternlab build)
• [x] patterns only (implemented as patternlab build --patterns-only)
• [x] serve
• [ ] export
• [x] help/usage information
• [x] init
• [x] list_starterkits (implemented as patternlab list-starterkits) (Will implement #465)
• [x] 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: https://github.com/pattern-lab/patternlab-node/issues/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.

[raphaelokon]

@bmuenzenmeyer Sure, we discussed that – I do not intend to break editions or any other implementations. Just wanted to point out that it would be the next rationale step. At some point it would be great to unify.

I would say add a deprecation notice in > v2.5.1. And merge of the CLI + lifting the editions would result in a major version lift for all … updating them to v3.0.0.

[bmuenzenmeyer]

Editions are separately semver'd from core, with both grunt and gulp editions being on on 1.X right now. In my mind the CLI could be introduced as a 2.X .minor point release to core if the current methods do not break, but this is something that we can figure out soon (and might be impossible, I'd have to look at the code in its entirety).

What's in a number? Well, at some point it is just a number, but Dave and I are both making strides to reduce breaking changes as much as possible to reduce upgrade pains.

Thanks again for taking the reins with this - I appreciate it!

[raphaelokon]

What's in a number? Well, at some point it is just a number, but Dave and I are both making strides to reduce breaking changes as much as possible to reduce upgrade pains.

So do I. I think tho that at some point if you change/deprecate APIs it is just fair to to the user to be transparent.

Sure … we will figure it out. :>

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bmuenzenmeyer]

closing this. the CLI has taken shape under the excellent guidance of @raphaelokon