Is there an "ALL of InuitCSS" bower package?

[iDGS]

The idea behind $ bower install --save inuit-starter-kit is grand! Love it!

Perhaps I've missed it, but how about likewise offering a pre-packaged "I want 'everything'" bundle of all the lovely InuitCSS bits and pieces? E.g., something like, $ bower install --save inuit-complete-kit

[iDGS]

Further on this topic...

(Background...) I just happened to notice you updated tools.mixins (AKA "inuit-mixins") by revising a comment and bumping the version number from 0.1.1 to 0.1.2. Well and good. So I did:

$ bower update inuit-mixins

and got a bunch of messages and a choice: ...

Unable to find a suitable version for inuit-mixins, please choose one:
    1) inuit-mixins#0.1.1 which resolved to 0.1.1 and is required by inuit-starter-kit#0.2.3 
    2) inuit-mixins#~0.1.2 which resolved to 0.1.2

Spiffy! Bower is awesome! (This whole versioning thing is in-and-of-itself a fascinating topic!)

I presume you meant to leave the Starter Kit as-is for the time being. I have no complaint.

However, in the case of this "ALL..." package I'm proposing, I'm thinking the right answer involves a manifest that keeps us sports fans updated to the latest and greatest stable version of each component. (Aside: I'm assuming if it's on Master, it's stable, ja?)

Yet, I'm looking at https://github.com/isaacs/node-semver#ranges and wondering how one specifies "give me the latest and greatest." Is it "*"? (At least to me, it's not so obvious. I don't personally equate "any version" to "most recent." So,...?)

Well, even though I don't know how to do it, I wanted to present the case that some users (hand raised!) might want a choice between different "flavors." E.g., some packages that remain stable at fixed versions, perhaps such as the Starter Kit, versus some, like "ALL...", that can be easily kept fully up to date with all of the "whatever's brand new and shiny" versions.

[florianbouvot]

You raised an interesting point. I think Harry should use caret operators. I personally use it with NPM packages so I only need to update dependencies when I switch to next major version. And it forces me to make sure everything works when changing version

[csswizardry]

I presume you meant to leave the Starter Kit as-is for the time being. I have no complaint.

Actually, I didn’t; starter-kit should always point to the latest versions possible. This was an oversight on my part, so thanks for flagging it.

I'm thinking the right answer involves a manifest that keeps us sports fans updated to the latest and greatest stable version of each component.

It would have to be the latest and greatest stable version of each component that are compatible with each other, which would be a huge overhead for me to keep an eye on manually.

This feature request in itself poses an interesting point though. One (of many) reason(s) I broke inuitcss apart is so that people can’t accuse it of being a bloated framework, or that it does too much out of the box, etc. By creating an everything repo I risk setting a bit of a precedent that I don’t want to. I know that inuitcss will still be a very unbloated framework, and that people choosing to download everything-in-one-go would be to blame for any bloat introduced, I don’t think I really want to provide that option. Developer 1 might choose to download the entire framework, and Developer 2 who inherits the project sees the amount of waste and would likely assume that it was inuitcss’ fault (‘Another bloated framework, look at all this stuff we don’t even use!’).

You could by all means create your own everything repo and point everything at "latest" instead of a version. This way you get your latest-of-everything, and I don’t have to maintain it :P

"dependencies": {
    "inuit-defaults": "latest",
    "inuit-functions": "latest",
    "inuit-mixins": "latest",
    "inuit-box-sizing": "latest",
    "inuit-normalize": "latest",
    "inuit-page": "latest"
}

[kursusHC]

Stumbling upon this thread looking for pretty much the same thing.

Harry I perfectly understand your point, but if Developper 2 who inherits the project comes to have a look at the bower_components folder, he will see around 10 folders, maybe more, saying "Inuit". Not the best way to think of an unbloated framework.

Could there be a way to use the categorization you created (settings, tool, generic, base, objects, components, trumps) since it has a good reason to exist ? It would make things more clear (easier to browse and to remember).

I guess creating folders would tie components together eventually (github and/or bower ?), which would negate the whole point :(

[nenadjelovac]

Developper 2 who inherits the project comes to have a look at the bower_components folder, he will see around 10 folders, maybe more, saying "Inuit".

Could there be a way to use the categorization you created (settings, tool, generic, base, objects, components, trumps) since it has a good reason to exist ? It would make things more clear (easier to browse and to remember).

This came to my thought at first, but I forgot to make an issue. Something like this would make sense in my mind in terms of browsing and remembering. And it would help when looking in bower.json and in your main .scss file. Here's an example.

"dependencies": {
    "inuit-settings-defaults": "latest",
    "inuit-tools-functions": "latest",
    "inuit-tools-mixins": "latest",
    "inuit-generic-box-sizing": "latest",
    "inuit-generic-normalize": "latest",
    "inuit-base-page": "latest"
}

@import "bower_components/inuit-settings-defaults/settings.defaults";

@import "bower_components/inuit-tools-functions/tools.functions";
@import "bower_components/inuit-tools-mixins/tools.mixins";

@import "bower_components/inuit-generic-normalize/generic.normalize";
@import "bower_components/inuit-generic-reset/generic.reset";
@import "bower_components/inuit-generic-box-sizing/generic.box-sizing";
@import "bower_components/inuit-generic-shared/generic.shared";

@import "bower_components/inuit-base-page/base.page";
@import "bower_components/inuit-base-paragraphs/base.paragraphs";
@import "bower_components/inuit-base-headings/base.headings";
@import "bower_components/inuit-base-lists/base.lists";
@import "bower_components/inuit-base-images/base.images";

@import "bower_components/inuit-objects-layout/objects.layout";
@import "bower_components/inuit-objects-bare-list/objects.bare-list";
@import "bower_components/inuit-objects-block-list/objects.block-list";
@import "bower_components/inuit-objects-ui-list/objects.ui-list";
@import "bower_components/inuit-objects-tables/objects.tables";

$inuit-enable-media--large: true;
$inuit-enable-media--rev:   true;
@import "bower_components/inuit-objects-media/objects.media";

$inuit-enable-flag--large:  true;
$inuit-enable-flag--rev:    true;
@import "bower_components/inuit-objects-flag/objects.flag";
@import "bower_components/inuit-objects-box/objects.box";
@import "bower_components/inuit-objects-buttons/objects.buttons";

@import "bower_components/inuit-trumps-clearfix/trumps.clearfix";
@import "bower_components/inuit-trumps-widths/trumps.widths";

[florianbouvot]

+1 for inuit-layer-module_name

[kursusHC]

@nenadjelovac This is better but still unnecessarily complex to me. I am currently real testing Inuit on a personal project and feel a huge pain in deploying/configuring the framework (despite I'm a long time Inuit user and lover).

I know it's alpha software, but I think this question should be addressed soon enough as it is critical.

Here are the steps I've been through to start working, as it's supposed to be right now :

• Install starter-kit and review the modules
• Browse through github to discover and review (unordered) modules one by one
• Install module one by one
• Create a main.scss from scratch : I give up after some time because the task is really painful (find a module, browse to find its category, remember category order, and after all check if all modules are loaded).
• Create a main.scss from doc sample : also too a long time (check both side, browse again to find category for new modules).

Eventually you start and realize you have no support for margin. Again :

• Browse unordered folders on github to find what you need
• Install via bower
• Edit main.scss (don't forget to remember the category)
• Browse the module file to check options
• Edit main.scss to activate options

This is a long and unpleasant process compared to a full (and commented) configuration file.

@csswizardry if the main reason for this new model is

Developer 2 who inherits the project sees the amount of waste and would likely assume that it was inuitcss’ fault (‘Another bloated framework, look at all this stuff we don’t even use!’)

please reconsider. Developer 2 will have a look at .css files before .scss ones. If Developer 1 is talented, the .css file will be light and powerful (if he's not, there will be a lot more to blame than the CSS framework) and Dev 2 will be happy. Same if he looks at a beautifully documented configuration file. If Dev 2 judges .scss files without even looking at the config file, then he is a bad dev. If Dev 2 is a bad dev, he will go through bower_components, see 15+ folders names inuit, maybe check the global size and see that it's almost 200ko, and eventually say "Inuit is bloated". So you shouldn't worry about bad devs. Or at least you shouldn't make good devs' life harder because of them.

Even if Dev 1 and 2 are good, the way it is now Dev 2 will look at main.scss and see a long and undocumented file. He won't say it's bloated, but will still have a very low opinion of Inuit.

Old gen Inuit.css was a model of clarity and simplicity (folder/module). It was also very fast to understand, globally and potentially (read the config file and you're done). You could set up a project in several seconds by uncommenting a few lines. Also it was a really good mean to spread and discover CSS best practices. That is precisely what most people loved about Inuit.

This is not the case anymore. The configuration system is (ironically) opinionated, and the problem will get bigger as Inuits grows :(

[csswizardry]

I need to give this a lot of input when I get more chance, but for now:

• Things aren’t documented because, as you say, this is alpha work.
• inuitcss isn’t here to do your work for you: you will need to create your own master file.
• inuitcss will make up the minority of your project, you will only call upon it when you need it.
• We need an index/directory of inuitcss modules, so you know what you need and when (see first bullet point).

I need to better document stuff, and I’m still hoping for a Kickstarter to fund that, and I also need to write up ITCSS which better explains the architecture.

[csshugs]

@csswizardry

[...] and I’m still hoping for a Kickstarter to fund that, [...]

+1 My purse is itching!

[florianbouvot]

@csswizardry :+1: for your Kickstarter campaign or any other things that will help you to accomplish your projects ;)

[emmanuele]

@csswizardry thumbs up for a Kickstarter campaign... keep up the good work!

[anselmh]

Hey, I’m going to close this issue for now. We are currently evaluating ideas for an upcoming next major version of inuitcss but it’s unlikely that we fix this in the current version. We do want to improve here so this one is going to be addressed.

Thanks for the contribution and idea!