Discussion: Add external scripts to starterkit import

[bmuenzenmeyer]

A user wants to create a starterkit which needs to have its assets transformed, such as preprocessed, optimized, or otherwise.

See http://www.brianmuenzenmeyer.com/adding-common-gulp-tasks-to-pattern-lab-node#comment-2814479313 for this conversation.

---

This is feature would let starterkit authors help consumers get up and running with more complex kits. Alternatives that I could think of:

• Prepackage the asset tasks within your custom edition. Afterall, that is what they are for, yes? This is basically what the point of the above linked article was.
• Put these build files inside source/js - which is a bit hacky but could get the js into another location. Then a user could write something similar to this in the edition to import the tasks.
• Create a build pipeline for the starterkit itself. This would allow a starterkit to ship with everything needed to start right now - but if you tweak one of these compiled assets you are then out of luck and need to regen and re-import the starterkit. This is a non-starter under most circumstances.

  System Input

• A starterkit, in addition to having a dist/ directory that mirrors source/, would contain an optional build/ directory that could contain scripts.

  System Output

• Upon starterkit load, the contents of build/ would be copied to build/ of the project filesystem.

The timeline for this feature is non-critical. I feel there are a lot of ways to workaround this issue already, but I wanted to include the discussion here for completeness.

Tagging frontend and spec-enhancement because this would affect how starterkits are loaded.

This is a discussion only and no vote is needed at the time.

/cc @pattern-lab/voting-members

[dmolsen]

@bmuenzenmeyer -

Reading that discussion highlights the differences between PHP and node implementations of Pattern Lab. I would argue that the poster is on the right track where the StarterKit has its own node dependencies/gulp/whatever. They'd craft their task runner in the StarterKit to call PL/node as appropriate rather than PL/node trying to dictate everything from the root of the edition. That's what I mean by PL being "yet another task." It should just be a task in someone else's task runner.

That's essentially how PL/PHP would work so that makes complete sense to me. For example, a gulp task in a StarterKit loaded into PL/PHP could watch for changes to ./_patterns and run the task that makes a command-line call to:

 php ../core/console --generate --patternsonly

The PHP version would update the PL related material (just patterns/view all!) as appropriate. If someone watched say ./css/ they could use Sass or Less, uglify, etc. and move to ../public/css as they see fit. An Edition of PL/PHP shouldn't have any sort of node dependencies itself. A StarterKit should have all of that.

Obviously the default is to move all the things but PL/PHP has an out for those deciding to use task runners. This is where PL/PHP has a really nice separation between task runners and PL proper. And this is entirely because PHP doesn't have task runners. I'm not about to get into dictating where they sort of stuff runs for node for the exact same reason.

As for the general notion that starterkit/build should be copied in a way that's similar to starterkit/dist I'm fine with that in general terms because I think it'd be straightforward to implement. I'd need to add a "build folder" config option and then modify InstallerUtil class as well as the Fetch command. I'm a little unsure of the actual usefulness of the build folder but, again, it's outside the process I would normally consider.

[bradfrost]

I'll just ditto what @dmolsen said. Thinking of PL as a dependency of someone's project seems more sane than trying to stuff all someone's dependencies into PL.

[bmuenzenmeyer]

Closing for now. Thanks