example of using inuitcss in a webpack project

[casertap]

I am trying to integrate inuitcss in my webpack app.
The webpack project I am using is using a custom loader to load bootstrap-sass which seams quite complicated https://github.com/erikras/react-redux-universal-hot-example/blob/master/webpack/dev.config.js

Is there any example on how to do that with inuitcss?

[anselmh]

Hey, currently there’s no example as we’re still in progress of porting over the individual modules to this new repo and improve it. Our plan though is to provide a way better documentation, including examples such as your requested one. Thanks for the request, we’ll try to provide it soon. :)

[mirkavolakova]

Do you guys have a time estimate for when the documentation could go out? Just curious.

[nenadjelovac]

@thosetinydreams it's not an ETA, but you'd be able to follow the progress here.

[mirkavolakova]

Cool, thanks, @nenadjelovac!

[nenadjelovac]

@thosetinydreams no problems ;)

[casertap]

If it can help, I have integrated the duckduckgo-styles in a webpack project:
https://github.com/casertap/react-redux-universal-hot-compass/blob/master/webpack/dev.config.js

This setup is complex because duckduckgo rely on compass and litestrap (itself relying on animate)

Note:

• add the entry point of your libraray in: entry: { 'main': [
• provide all the necessary path used at compile time in: sassLoader: { includePaths:
• specify the import that should be added explicitly in all file in: sassLoader: { data:

[nightgrey]

Hi!

I'm also using webpack with inuit.css. I'm using postcss-loader + sass and my main.scss (which get's imported by my root React.js component) which looks like the example main.scss provided. Works fine.

If you want an example, see https://github.com/nightgrey/3dstheme-portal and check out this files/folders:

• src/browser/app/Root.js (main.css get's imported here, all components have their own .scss file)
• src/browser/styles/main.scss (main.scss from the example)
• webpack/config.dev.js (Webpack configuration)

Essentially, the workflow is not different from any other sass library and/or file.

I also have a problem/suggestion for those using inuit.css in webpack. I'm not sure if the place is correct or if I should create a new issue. What do the owners think? I'll write it down here for now, I can move/edit if desired.

Problem/suggestion
The only problem I have (and it's likely this will occur in the future!) is that webpack does not work like, f.e. gulp-sass. If you want to have variable A from file A in file B, you have to import file A in file B, because the order of the generated CSS is NOT guaranteed in webpack. Just importing it somewhere else works sometimes, but purely on coincidence.

Example
In my case, I wrote my own spacing utility which is imported by a component of mine. But - the compilation fails because my spacing utility needs an inuit-variable, Undefined variable: "$inuit-global-spacing-unit".
Now, I can easily fix this by importing the file where the variable is defined, but would this not have been my own spacing component, I could not have done this.

Solution/proposal/idea
I'd like to see inuit.css built with this in mind, i.e. importing the files/variables it needs in every file. That's the only way it will work properly in webpack. But..

• would this break for a user with gulp/grunt/other build system?
• is there another solution besides importing all SCSS files in the project from one main.scss? I actually don't want to do this and keep my component's code together with their JS, so it's nicely together.

I'd do a pull request for this if this is something desired by the repo owners. I'm also not sure if that's just my problem. Maybe all other guys are using one main.scss and boom, done. How do you guys do it?

[herzinger]

@nightgrey I don't think the problem occurs from the reason you described, but I did face this when trying to make some js components work independently from my project's main code base, and the same would happen if you use injected stylesheets, like with the style parameter in angular components. The solution you suggest is not a great one by itself, since if you have more than one file with the same dependencies it would make duplicated code in the output. That's because sass' imports are triggered every time they appear.

A better idea would be to implement an "import-once" kinda thing. It's one of the features confirmed for sass 4, but until then there are some custom solutions out there, and I have an idea on how to make one, based around dependencies declarations, that would suit inuitcss. If there is interest I can make a PR.

[herzinger]

Also, it would be great for documentation, since each piece of code would have it's dependencies declared.

[nightgrey]

@herzinger

I don't think the problem occurs from the reason you described

You mean that compilation fails (in my given case) because webpack's order of importing JS and SASS/CSS is not guaranteed? It actually is the cause of the problem. Check out these quotes from webpack developers:

From webpack/webpack#215 (comment)

The order in the bundle is not the order they are added to the DOM.
The oder in the bundle depends on the module id. And the module id depends on how often the id is used and alphabetical order. Or is random in dev mode.

From https://webpack.github.io/docs/stylesheets.html

Keep in mind that it’s difficult to manage the execution order of modules, so design your stylesheets so that order doesn’t matter. (But you can rely on the order in one css file.)

That's why you're importing, f.e., React in every file you need it.

The solution you suggest is not a great one by itself, since if you have more than one file with the same dependencies it would make duplicated code in the output. That's because sass' imports are triggered every time they appear.

Huh. I didn't know this (and didn't notice), but you're right! Thanks. In this case, my solution is pretty bad. I assumed Webpack uses the DedupePlugin like with JavaScript. Seems like it doesn't work with SASS.

Also, I'm curious about your idea! Do you mind explaining?

Edit:

I just found this. There are others like sass-loader-once, but it just imports once, it does not sort anything or checks what file needs which import, so some variables are still be undefined. I'll check fast-sass-loader and report back. It might be a workaround until inuit.css itself has a solution, or there is a preferred official solution by inuit.css or Sass.

[herzinger]

This has nothing to do with @import order. If it was the case, it would be impractical to use, since source order is pretty essencial for css (and one of the main points of ITCSS). This happens because you want to load partials directly in your modules, and those modules are loaded without an predefined order. If you were to use a single stylesheet loaded in full only once, it wouldn't be a problem.

What you need is a way to declare and load dependencies, as I said. It's really necessary to be able to take full advantage from module loaders, especially with stuff like Angular 2. I'll make the PR I mentioned anyway, and we can take it from there.

[nightgrey]

@herzinger I think I could've put it better, but I'm pretty sure we're talking about the exact same thing, we just misunderstood each other. Sorry for the confusion.

To make it clear: I'm not trying to say the import order WITHIN a file is random. The order is as expected if I import file C after file B in file A - no argument here. It would be awkward if this was random, and yes, order is ITCSS whole point. I also know why my example in my first post in this issue fails. That's why I'd like to see this to work like in JavaScript - with declared dependencies. The exact same thng you're talking about. ;-)

Please make the PR (or maybe an example)! I mean, I get what declaring dependencies is, I just can't think of an actual example without duplicate imports/code output.

[herzinger]

Can someone from the core team comment on this? As it's considerable work, and after some of my last submits, I don't want to jump into it before making sure it'll be used. Some points:

1. I know there is demand, both from this issue, from conversations on the slack channel and from real life. I would use it myself, for one.
2. It would NOT add value for everyone, apart for self documentation. New partials would need to declare their dependencies of other partials, and it would only be good (great, actually) for users of module loaders like Webpack or SystemJS. It would bring awesome value for users of stuff like React and Angular 2, but not for others, although it would not hurt them either.
3. It would require work across the framework, so making a plugin is not an option.

I'll do it anyway, since it's great for the kind of work I do, but depending on the answer I'll do it in a fork, and without much hurry.

[csshugs]

@nightgrey @herzinger
cc @inuitcss/core

To be honest, I never used webpack in my life. I barely now what it's good for and all you have written about above, I don't really understand 😞.

That being said, I'm not exactly sure what's being expected from us here? In the first place, I assumed it's just about a documentation thing of "how to use inuitcss in a webpack project", so we would write some instructions like: "do this and that in your webpack config file, and make sure you don't forget to..." and that's it.

After re-reading this thread, it seems like we have to completely rewrite our code, just to be able to be used in a webpack project. If that's the case, it rings some warning bells in my head, because I always believed that any kind of CSS framework should be able to be used in any kind of build tool or whatever environment without doing any kind of specific work for the respective tool it's being used in.

Can you please elaborate, what you specifically expect from inuitcss to be able to be used in a webpack project?

[herzinger]

@csshugs That is not the case. The feature I suggested is necessary to use one of the great features of module loaders, that allow you to encapsulate the style for a component together with said component. It means you could distribute it as a single .js file, with no other dependency, having both style and template embedded in it. It's great, specially for bigger projects and for stuff that can be reutilized often. You can still use inuitcss as is by linking a main css file in your project index like normal (with a little extra setup), you just would loose a lot of the modularity of your components (which is the main reason to use a module loader in the first place).

It also wouldn't mean completely rewriting inuitcss. What I meant when I said "It would require work across the framework" was that I would make a small addition to each partial, and it would need to live there, so there's no way to just add some external files to the project and get it to work, like a plugin would.

[csshugs]

@herzinger I'm sorry, but I still don't know what we would have to do exactly to suit your needs. Do you have any code examples of what we would have to do?

I'm sorry for my newbie knowledge concerning this topic, but I really have to understand this thoroughly to judge about it.

[herzinger]

It's worth to note that I don't believe any mainstream css framework is ready for that quite yet. Popularization of module loaders is a pretty new phenomenon (I believe it to be the next big front-end paradigma, to be honest), and this particular solution is something from the top of my head. I never saw it implemented - although I do know it works.

SASS 4 is expected to ship with @import-once, which will make implementing this even easier, but it's still in alpha 1 and I believe we would still support SASS 3x for some time even after that.

[csshugs]

@herzinger

It's worth to note that I don't believe any mainstream css framework is ready for that quite yet. Popularization of module loaders is a pretty new phenomenon

Ah Ok. That confirms my scepticism.

[herzinger]

@csshugs It's a dependencies injection/declarations system, but that's okay if you don't understand for now, I would do it myself. I just want to know if, knowing the points I presented, it's something you would be okay seeing in inuitcss.

[herzinger]

@csshugs bottom line: for this to work, each partial has to be able to function by itself. It has to know if everything it needs is there, and if not, load it in the correct order. When you write a component, you link it to a single file, and it's loaded on demand.

[csshugs]

Giving this fact:

It's worth to note that I don't believe any mainstream css framework is ready for that quite yet. Popularization of module loaders is a pretty new phenomenon

... IMO it's not something to be implemented now (i.e. for version 6.0.0). If it's still an upcoming trend, I think it would be sensible to wait how this concept develops in the CSS community.

And don't get me wrong: It sounds like a great concept. I just don't want to navigate inuitcss into a deadlock.

[csshugs]

bottom line: for this to work, each partial has to be able to function by itself. It has to know if everything it needs is there, and if not, load it in the correct order. When you write a component, you link it to a single file, and it's loaded on demand.

Copy that! Thanks for explaining.

Let's see what @inuitcss/core has to say about it.

[herzinger]

Okay, I'll make a fork them, for now, and link it here after it's up. I follow inuitcss for many years now and kinda see it as a trend setter, so I would be happy to see it ahead of the curve once more.

[csshugs]

Since we don't consider this topic to be relevant for inuitcss currently, I like to close this for now and see how the CSS community develops in the future and think about this again, when it is a more common standard in the community. Until then, we are keen seeing forks of inuitcss addressing and incorporating this.

Thank you @herzinger for explaining things thoroughly and everyone else for their opinions in this discussions.

[yourownmood]

I have setup a boilerplate with "create-react-app-typescript" which includes a way of working with inuitcss. https://github.com/yourownmood/react-inuitcss-boilerplate

Maybe you can borrow the same approach of handling scss and inuitcss in your project