SCSS file naming and output in gulp task

[occupant]

Right now, we have the following structure:

src > sass > MAIN.scss

This adds all scss files, and when gulp is run, resaves it as:

• dist > css > ubcclf.css
• dist > css > ubcclf.css.map
• dist > css > ubcclf.min.css

I'd like to propose we change the naming and change the gulp task to do things slightly differently.

Name: we should use a much more generic name for the output. And, ideally, use the same name for input and output to aid in clarity. I suggest styles-all.scss. This would be accompanied by a styles-minimal.scss file that outputs the bare minimum of base styles and helpers.

Gulp Task: we should remove the explicit file references and allow the tasks to be run on any scss/sass files in the src directory. We should also include a file to allow a single component or set of styles (ie. grid) to be rendered on its own. These should be kept in the same directory as the component itself and simply include the needed @import statements.

We should also indicate that file versions with sourcemaps (and the sourcemaps themselves) are not for deployment. I suggest adding a .dev suffix to the filename to indicate this, but perhaps moving them to a subdirectory would make more sense. Minified versions of files get a .min suffix.

The minify task may be irrelevant if we do this (and we'd want to come up with a better task name than 'components', but it will do for illustration purposes).

If we do this, the result would be: src > sass > styles-all.scss compiles to:

• dist > css > styles-all.dev.css
• dist > css > styles-all.dev.css.map
• dist > css > styles-all.min.css

And components such as: src > sass > components > component.navigation.drawer.scss compile to:

• dist > css > components > component.navigation.drawer.min.css

I'll attach a pull request with the proposed changes to the dev branch.

[hazuremon]

Thanks @occupant

Name: Will it be more beneficial to have an identifier? While we will provide this through CDN, users may save this locally for different purposes. i.e. CWL login page. Adding an identifier may help identify UBC-DEF resources quickly?

Gulp: Remove explicit reference make sense, it should be more flexible to allow to run on other directory.

We should also indicate that file versions with sourcemaps (and the sourcemaps themselves) are not for deployment. I suggest adding a .dev suffix to the filename to indicate this, but perhaps moving them to a subdirectory would make more sense. Minified versions of files get a .min suffix.

I also agree moving the dev files to a subdirectory instead, it will clearly separate what is for production and development use. Adding .dev may help to differentiate them visually but moving them out to different directory maybe a better route to go. While we can explicitly indicate sourcemaps and dev files are not for deployment, I would suggest to have a more proactive approach to prevent users from accidentally deploying dev files.

I need more information on the proposed components setup, is the intention to have its own individual CSS file for each component we built? Is that more for the component builder that we previously discussed? Trying to understand which approach will be more beneficial for our regular CLF users and for our developers.

[richardtape]

If the styles-minimal stuff is what is absolutely required to show a page properly, could it be styles-critical as some folks would then understand what it is, and hardcode it in their templates.

[occupant]

Thanks both.

Name: I should have also clarified that I was assuming this was NOT specific to the CLF, but the framework. A CLF implementation should follow those rules you mention, but this being the more generic implementation is why I haven't incorporated any CLF nomenclature (required, etc).

Gulp Task: Ok, I'll adjust the dev files to go into a new dist/css/dev subdirectory. I agree this is cleaner.

The proposed component setup is to allow us to generate partials / self-contained components. We could do this at a later point, but my thought was that this is just a framework, not specific to the CLF, so the component builder wouldn't necessarily apply. Also, making the components self contained makes it easier to test them. I'm happy to abandon that if you both don't see a need for it though.

[occupant]

And I like styles-critical - that plays nicely with the idea of critical inline css.

[richardtape]

I like the idea of having the components as separate files. It makes sense on several levels and lowers the barrier of entry to contributing to the project. As you say, they're more easily testable. Furthermore, we could have a separate task which keeps them as separate compiled files should someone wish to have them individually because they're in an environment with high availability of http/2 clients.

[hazuremon]

Thanks both.

I must be jumping ahead then, it makes sense now after clarification.

[occupant]

Great, I'll resubmit the PR with the changes discussed, clean up the formatting (I still hadn't been using the editorconfig file), replace the minify task with the components task, and add the lint task to the travis test.