Distribution for "helper" scripts

[jeffposnick]

There are a number of novel things you can build on top of the core sw-toolbox library, e.g.:

• Offline Google Analytics
• An Appcache-manifest converter
• A set of cache strategies for resources distributed on common CDNs
• your idea here

We should come up with a standard way of distributing first-party helper scripts.

Possible approaches:

• Creating a helpers or addons directory within the main project. This would make the helper scripts more discoverable, but versioning them sanely would be difficult.
• Creating a new sw-toolbox-helpers repo to host them all en masse. This would be less discoverable than if they were bundled with sw-toolbox, and versioning each script independently of the others wouldn't be possible.
• Creating a new sw-toolbox-helper-XYZ repo for each helper script. This would have similar discoverability problems but we would be able to version each helper script properly.

Thoughts? CC: @wibblymat @addyosmani

[addyosmani]

I would vote for a sw-toolbox-helper-XYZ style repo for each helper. This allows them to be independently versioned, included as more modular dependencies and can be linked up from the project docs (so at minimum it's got the same qualities as the second option).

[wibblymat]

Do them all independently. This has the added advantage of not privileging first-party plugins over third-party ones, like with gulp/grunt plugins.

[ebidel]

I'm usually in favor of separate repos, but in this case it might be daunting to create a repo for each helper, maintain that, have users search over them, etc. That's potentially 100s! A repo for all helpers would be nice.

My thinking is that most helpers will be very small (2-3 LOC) and ultimately, most developers will want to use several at a time. Bringing down a single repo with everything would be great. For starters, we can start with 1st party (well known) plugins.

[addyosmani]

I initially voted for us to separate these out into their own dedicated repos, but on re-thinking the problem space we aren't going to have a lot of helpers that are particularly large or complex. It may make sense to initially just have a master repo and if the collection of helpers grows sufficiently that we need to split them out, we can always do that later and submodule them back in. Does anyone else strongly feel we should split these out?

[gauntface]

I'd vote one separate repo to contain them all and see what the response is like.

Anyone have any ideas on criteria for acceptance?

[jeffposnick]

If we assume that npm will be required to install these helpers, then we can use an arbitrary number of subdirectories within a single repo, each with its own package.json maintaining independent versioning, and share a global top-level build/test/publish script.

This assumes that we're okay with being unfriendly towards bower because we won't be tagging repo-level versions.

[gauntface]

If we can have a separate package per subdirectory that would be awesome!!!

[jeffposnick]

Oh, so this is apparently referred to as a "monorepo", and it's A Thing: https://github.com/babel/babel/blob/master/doc/design/monorepo.md

There's a tool for working with this structure (https://github.com/kittens/lerna) but that seems to focus on needing to version all the individual modules with the same release number, which we explicitly don't want to do. So just versioning them by hand should work.

[jeffposnick]

Here's a good monorepo example that we might be able to learn from: https://github.com/danigb/tonal

I don't think we'd want the single-version-semantics implied by using https://github.com/kittens/lerna, but we might be able to learn something about overall repo structure and generating documentation (via https://www.npmjs.com/package/documentation, it looks like).

I'm putting together a formal proposal that I'll circulate for comment and feedback, and then we can move forward.

[gauntface]

Sounds awesome thanks Jeff

On Fri, 18 Mar 2016, 21:26 Jeffrey Posnick, notifications@github.com
wrote:

Here's a good monorepo example that we might be able to learn from:
https://github.com/danigb/tonal

I don't think we'd want the single-version-semantics implied by using
https://github.com/kittens/lerna, but we might be able to learn something
about overall repo structure and generating documentation
http://danigb.github.io/tonal/docs/ (via
https://www.npmjs.com/package/documentation, it looks like).

I'm putting together a formal proposal that I'll circulate for comment and
feedback, and then we can move forward.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#33 (comment)

[gauntface]

@jeffposnick do you think we can close this issue now?