Builder as installer for NPM scripts about builder HOT 7 CLOSED

One of main thrusts here is really is "it's almost npm" for the scripts in the archetypes, etc. And we're trying to keep it simple, understandable, and potentially give a road "back" to NPM (remove builder without too much pain) if things don't totally work out.

The few things why there is I think a need for something beyond just package.json and files in the repo is a use case we're hitting in our OSS and client work:

• You have multiple (10-40) component repos that all have basically the same package.json scripts + config files.

Managing that via each repo is a pain, particularly when you find that one of your package.json:scripts commands has a bug and/or your config files need changes, etc.

Builder allows to you just take a dependency, manage expectations via semver and have "one source of truth" for common tasks across very common, but independent repositories.

Once you've got that use case, the things Builder offers are:

• Archetypes: The solution to the above problem. A way to define a specific set of tasks / configs / etc for one "type" of project. For us, that is the ever-expanding set of our https://github.com/FormidableLabs/?utf8=%E2%9C%93&query=victory repos (still have to roll this out, but it's our primary use case driver).
• Flexibility: Most of the meta tools I've used in the path are of the "buy the farm" nature. Work great when everything is within the workflow but fall apart once you want to be "just slightly" different. Builder solves this by allowing fine grain task overriding by name, where the larger composed tasks still stay the same and allow a specific repo's deviation from "completely off the shelf" to be painless.

It's also got the "nice to have" of a cross-OS compatible concurrent task runner (but you can get this as an independent node modules like concurrently, so not the biggest "thing" for a runner).

I think you're right in that Builder doesn't perhaps shine and isn't perhaps the best solution for:

• One-off repos. The project is specific enough and is the only thing that a group of folks manage.
• Beginning / learning node projects. One of the things we've just admitted for our Victory components is that a modern, publishable React build for these components + supporting lots of workflows + having a test driver infrastructure is complicated. And our build for these is meant to be efficient, robust and unfortunately, is not necessarily accessible in the straight build itself to completely new folks. (It is expected that new folks / old folks / etc can easily use Victory components in their projects with very basic workflows and builds...)

from builder.

@ianobermiller ... thinking about this for a little bit longer, I guess the alternatives / refactors to builder that would potentially suite our workflows:

• npm implements a plugin / module system to handle archetype-like scripts + dependencies. (But we're waiting on something in core npm...)
• We refactor builder to instead of using installed archetypes in node_modules/ARCHETYPE/package.json to instead rewrite and mutate a project's package.json and other various files. (I think capturing what you might favor?) However, this becomes really tough and complicated once a project goes "off script" and wants to override just one scripts command when you consider the upgrade scenario for the archetype -- you're dealing with real code diffs + merges + potentially having an archetype upgrade blow away your customizations. Perhaps there is a sane way to manage the conflicts, but on first considering this approach this morning, seems... complicated and risky.

Put another way, I agree with the sentiment of not wanting "yet another task runner / meta tool", and this is the smallest / "least" task runner I could come up with to meet our use cases 😄

Love to hear your thoughts more, but perhaps you could aim to direct this issue into something actionable for builder (like a strawman refactor / rearchitecture) or close it?

Thanks!

from builder.

Apologies for the hit and run, I haven't taken the time to properly respond. I think I was not quite understanding the target use case of having an npm-installable set of common scripts for multiple projects that basically work the same (e.g. a bunch of plugins). I think that is the great sell for builder, and it is definitely missing in the first three introduction sentences, and only alluded to in the overview.

from builder.

+1 for capturing this in the readme

from builder.

I think that is the great sell for builder, and it is definitely missing in the first three introduction sentences, and only alluded to in the overview.

Great point. Thanks @ianobermiller !

from builder.

I just saw butter-run-npm, which gave me a simple idea that you could keep the npm scrips, and just point them to builder:

"scripts": {
  "dist": "node ./node_modules/builder run dist"
}

Builder could even add these shims for you automatically. This would solve the main problem of yet-another-tool for end users.

from builder.

@ianobermiller -- Yeah, the notion of doing environment variables + working with npm scripts is something that needs to be outside NPM for cross-platform because of the differences in env variables.

We're still working out whether or not (and how) to mutate an underlying project, and we're actually retooling the relationship of archetype scripts, dependencies and devDependencies to be more straightforward for consumers (#18, FormidableLabs/builder-react-component#6)

Also to hopefully fight the "yet another tool" issue, I'm currently writing up a section on "how to abandon Builder and go back to straight npm" as a guiding principle to keep it simple and aligned with npm

from builder.