spectrum-web-components

spectrum-web-components copied to clipboard

Proposing converting as much as possible into a CLI so that downstream projects can inherit a versioned clone of this without having to copy or fork the repo.

Benefits

• Keeps tooling consistent between related projects
• Separates component development from tooling

Scope

1. Migrate existing tooling
2. Add command for creating a new "spectrum" repository (cc @Westbrook for more discussion on this)

Implementation notes

• https://blog.npmjs.org/post/118810260230/building-a-simple-command-line-tool-with-npm.html

💯

Initial Questions:

• There are a number of different types of "down stream repositories" that we might want to support. I know it's early, but what sort of contexts might you be looking at supporting?
• What level of variance (if any) do you think this sort of offering would need to either support or prevent? e.g. fully extensible, locked down, a bunch of radio and/or checkboxes, etc.
• Are there specific tools that you've started to mark as being desired in this way? Some are certainly more "mobile" than others, but some might be worth the investment to make so.
• I've used Plop a lot in the past, any thoughts on the benefits between something like that and the npm init ... context you've linked?
• Does "keep tooling consistent" shake out more like a sharable tools package such that whether you're working a Spectrum repo or adding a Spectrum component you can interact with this in a similar way? Particularly effective when a contributor wants to work ahead of the library with a component implementation that should be shaped a certain way when it actually becomes a contribution to the library.

I'm taking my inspiration a bit from the rocket-cli: https://github.com/modernweb-dev/rocket/blob/main/packages/cli/package.json

I'm thinking it would be beneficial to break down our top-tasks and map those to generic commands:

• swc init - stubs out a standard web component library ready for spectrum-compliant development
• swc new - runs the generator to build a new component
• swc build - builds components for publishing
• swc test - runs tests
• swc docs - build the documentation

Tell me more about a context in which you'd expect to see a large enough number of "spectrum-compliant libraries" spun up to need something like swc init? Certainly a lot of power there, but I'm not sure I understand the user base that you see targeting with such a feature.

For new, build, test, and docs, what do you see being the delta between this sort of approach and the repo generated above simply having those commands as NPM scripts npm run build or yarn test?

The UEC repo is an example of this - currently it's a clone of this project which isn't ideal. When your 11ty updates merge for example, then there's a lot of work to do to bring the UEC repo back in line. It's too easy for forks or copies to get out of sync with the original. As for supporting spectrum-compliant libraries, I can see a few use-cases already and I'm sure we'll find more as we go:

1. UEC - components that combine SWC into groups and layouts to make implementation easier and more defined
2. Labs / experiments - components that are being tested but not hardened yet or not yet fully vetted; goal to migrate to SWC core eventually

I suspect a lot of use-cases that crop up will be in the realm of internal Adobe web components that we aren't ready or able to open source; or components with business-logic baked in for convenience but that uses SWC's framework to standardize development.

For new, build, test, and docs, what do you see being the delta between this sort of approach and the repo generated above simply having those commands as NPM scripts npm run build or yarn test?

UEC can still have a script for npm run build but it would point to: swc build which is installed as a dependency. This pulls the build tooling out so that as it evolves and migrates, a project using it just needs to bump it's version to get the latest build fixes and changes.