search

caxy / kss-caxy-zaba-template

Caxy's Zaba kss-node builder template.
MIT License
0 stars 1 forks source link

Sort out asset order and location #3

Open beckkramer opened 7 years ago

beckkramer commented 7 years ago

Pulling together some thoughts here.

The Sass included in this builder is expecting the following, in this order:

  1. Defining a set of variable values
  2. Pulling in normalize (node package)
  3. Pulling in a flexbox mixin file
  4. Pulling in a general mixin file
  5. Pulling in a specific Sass file from project-specificdefining color and breakpoint values
  6. Pulling in additional styleguide/KSS-specific Sass

This is problematic in this new context, because Normalize is not currently set as a dependency, and there is a defined path in place that may or may not actually exist, as it's outside of this builder's folder (../project-assets/project-specific).

My current thought is not counting on the caxy-zaba.scss file itself to pull all of these partials/dependencies together, but rather manage this in a separate JS file.

jschroed91 commented 7 years ago

@beckkramer RE: the project-specific.scss file - I actually had a modified version of caxy-zaba.scss working in this project before, and I had removed that include from the file. The caxy-zaba.scss file somehow got overwritten with the compiled css version of itself - I think while working in developing the system for compiling the scss in the builder itself... not sure how I didn't notice that.

In the starter kit PR, I actually have the project-specific.scss file that lives in the starter kit repo added in the styleguide configuration so that it gets included. I had made an assumption that it wasn't a requirement for this template, but it sounds like it might be? Wonder if we should have a default file in here that gets used if there isn't an external file passed to the builder?

beckkramer commented 7 years ago

Yeah- the probably-more-complicated-than-it-needs-to-be part that's the stumbling block right now is that file specifically. It's basically acting as an in-project reference to color and breakpoint values that then gets pulled into the styleguide for use in swatches, etc.

Having the styleguide reference an outside file vs needing to re-enter all those values in a second, styleguide-specific spot is the issue at hand.