How do we consume bitstyles

[planktonic]

Bitstyles is currently untried in a project; would be great to setup a new project consuming bitstyles to run through the whole process/as much as possible. What can we do better?

[sonniesedge]

Some initial results:

• Importing v0.2-alpha via Bower - node_modules resources fail #68
• Importing v0.2-alpha via npm - node_modules resources fail #69

[sonniesedge]

We need to consider either the release method, or how 3rd party modules are included.

Release method:

• What alternatives are there to Bower and npm?

3rd party modules:

• could be included in the repository. An easy fix, but makes tracking changes to upstream resources very hard.
• could be included as git submodules. Would these be included in the release files? UPDATE: No, they aren't. github package with a git submodule dependency? wbond/package_control#126 (comment)
• We need to determine why 3rd party dependences are not being imported.

[sonniesedge]

How do we import Bitstyles modules? Are we assuming that a project will pull in bitstyles.scss only and that it will pull in everything else, or are we assuming that a project will pull in each Bitstyles modules individually?

Single file

Pulling in one file would be neater and easier when setting up a project. We can use a settings override file to turn on and off various components.

Multiple files

Pulling in multiple files would give us fine-gained control over every project, just including what we need. More initial work. Would by pass many of the relative path issues that seem to be cropping up.

[planktonic]

Nice! Thanks for trying this out

single/multiple
I like the single file approach for simplicity — it’s a single package to add to a project — but I really appreciate the control, optimisation & clarity possible with a multiple file approach. Even though both make it possible to include/exclude css components, using a single file import means some other mechanism is needed (e.g. setting sass variables to control with are included) whereas multiple files can be explicitly imported in exactly the same way as a project’s css components.

Multiple files also means we can interweave project components with bitstyles components while sticking to ITCSS-ish principles.

Recent github pricing changes make the multiple approach more tenable I think — like inuit v3 we could use multiple repos. One of those repos could contain only the manifest main.scss with everything commented out to use as a starting point for new projects?

Then we’d have the problem of ensuring all settings & mixins are included when importing a component (as with inuit v3)…

It’d be great to talk this (and 3rd party dependencies etc) through tomorrow/in the next couple of days? I reckon it’d be quicker

[sonniesedge]

Sass module loading

How do we load the Sass modules? Personally I'm for multiple file imports. This allows selective importing, selective ordering and is simpler to maintain than having multiple settings and checks. It's not clever or fancy, but would work and be reliable.

A single file would appear to be a simpler way to import to a project. But we'd still have to copy-and-paste in a settings file. It also has to be balanced out against the time it would take to build and maintain settings and checks.

Multi-repo vs Single-repo

The Inuit multiple-repo system is one of the most confusing setups I have ever seen. I can't see any advantage to splitting each component into a separate repo. It's not like we'd compile the entirety of the single-repo Bitstyles modules into an end-project and have it all built into the final CSS file - we'd selectively load modules, whatever method we used to do that.

3rd party dependencies

These are the current stumbling block. npm is inconsistent in how it imports these across versions - relative paths can change (not a problem for JS, but a problem for CSS/Sass). We'd be using Bitstyles in potentially unfriendly codebases where we can't control node versions or Sass types/versions. The more we can reduce dependencies that can cause complications, the better.

Removing dependencies would also allow us to offer this via Bower, which we currently can't do, due to postinstall scripts and dependency resolution.

[sonniesedge]

Come and talk to me about this if you want to discuss this. I just wanted to get my views recorded before hand.

[planktonic]

👍

This allows selective importing, selective ordering

This and the dependencies seem to me to be the priorities here. Multiple repos is only any good if it fixes one/both of those, while single cannot (definitely a simpler structure than inuit would be good)