[Distribution]: Node Package or Webhook or something else

[joshbruce]

Issue type

• Distribution

  Details

The goal of the SAM Web Design Standards is to consolidate and normalize the:

• CSS - minified
• JS - minified
• Images for front-end elements and components
• Fonts for use by the front-end

The question on the table is:

Do we want to make this available through NPM?

Or, we we make it a web hook against the platform that gets fired whenever a merge is put into the main gh-pages branch to bring over the src and compile from there?

Or, some other option...??

There are ups and downs to both. How do private repos affect the decision?

[joshbruce]

Should we make the UI kit js an NPM then include it into the Standards - or include the Standards into the UI kit?

[diego-ruiz-rei]

I'd imagine the standards could work without the UI kit, but not the other way around. Leaning towards just including the Standards into the UI kit.

[joshbruce]

Interesting observation. To make sure I'm understanding correctly:

1. As part of the gsa/ui-kit-js/package.json - we would have a dev dependency on the gsa/sam-web-design-standards.

Results in:

- ui-kit-js
  - node_modules
    - /sam-web-design-standards

1. Rather than a dev dependency in gsa/sam-web-design-standards/package.json on the gsa/ui-kit-js.

Results in:

- sam-web-design-standards
  - node_modules
    - /sam-ui-kit-js

I know @tarandhupar was thinking along the lines of 1. And I was going the other way (2). Or, did I completely miss the boat?

Throwing copper moment

Some questions that just came to mind: Could they both stand alone? Really alone?

Something like:

- project
  - /public
  - /node_modules
    - /sam-web-design-standards
    - /sam-ui-kit-js

Then, if we ever decided to do something like sam-ui-kit-rails - then I, as a developer (thinking outside developer), could just include a different kit into my project. Or, I could create my own Sass and whatnot that plays with the HTML from the kit.

[diego-ruiz-rei]

I was leaning more towards (1).

On the "copper moment", I don't think the kit could truthfully stand by itself. If we want to be able to resolve the following:

- project
  - /public
  - /node_modules
    - /sam-web-design-standards
    - /sam-ui-kit-js

For npm ver2 we might want to look into defining a peer dependency from UI kit to the SAM Web Standards.

Looking at the documentation for npm ver3 and up, I believe the new flat structure implemented by ver3 will already structure like the above

[joshbruce]

@diego-ruiz-rei - Compelling points.

I agree, the kit HTML patterns won't aesthetically look proper without the SAMWDS (or something like it)…similar to using Twitter Bootstrap (where the SAMWDS is analogous to Twitter Bootstrap).

I’m curious if we are viewing the kit as being client-side-only? (As the SAMWDS are inherently the client-side assets.) Is the kit something that could be used in conjunction with a server-side template engine for Node (Handlebars or Mustache, for example), similar to if we had written the kit in Java for use with Thymeleaf? (No client-side assets necessary outside the kit.)

Does the kit being a private repo/package as of now matter? (Is that a compelling case for web hooks as well?)

Also, considering the future and agility: On a scale of 1 to 10, with one being a "piece of cake" and 10 being Herculean, how difficult would it be to change in the future?

I have a guess for myself, and would like to hear from others more familiar and before creating any sort of confirmation bias for or against the question within the thread.