search

codeforamerica / honeycrisp-gem

A Rails gem with base styles and Javascript for Code for America products
http://honeycrisp.herokuapp.com
MIT License
24 stars 8 forks source link

Namespace stylesheet importing #260

Closed hartsick closed 3 years ago

hartsick commented 3 years ago

I would like to move our stylesheets into a honeycrisp directory so that we can more easily override specific modules in our host applications. I think this would make Honeycrisp as a whole a bit more modular, which would support projects like CMR or GYR to implement new styles without overriding or ripping out Honeycrisp as a whole.

Current state

Currently, our modules from Honeycrisp are imported at the root of their asset search path (not namespaced). So our import file would currently look the same as cfa_styleguide_main.scss, or:

@import 'atoms/grid';
@import 'atoms/base';
@import 'atoms/spacing';
etc

This means if we have the same filestructure in our apps (atoms, molecules, organisms) it's hard to differentiate which imports are ours vs Honeycrisp's. From what I can tell, we also need to name ours differently, if selectively importing.

Proposed change If we were to move our stylesheets into a honeycrisp directory, we could instead reference them like so:

@import 'honeycrisp/atoms/grid';
@import 'honeycrisp/atoms/base';
@import 'atoms/spacing'; // custom spacing for our app
etc

Bootstrap is a good example of a library that uses this technique. The stylesheets path: https://github.com/twbs/bootstrap-rubygem/tree/master/assets/stylesheets/bootstrap, which can then be referenced in application.scss as:

@import "bootstrap/alert";
@import "bootstrap/badge";
etc

Impact of change I think that because all of our apps currently import stylesheets through the manifest (cfa_styleguide_main), there will be no impact to host applications. But, it would immediately help us on CMR, since we are beginning to import specific modules.

Possible related changes

  1. Namespace Javascript and images: It also seems that bootstrap does the same with Javascript. I think that's reasonable and am pro moving them, along with our image files. I believe both images and Javascript moves might be breaking changes for teams, so would like to handle them independent of this issue.
  2. Update SCSS files to leverage Sass modules. Of note: One year after this deprecation goes into effect (1 October 2022 at latest), we will drop support for @import and most global functions entirely. This will involve a major version release for all implementations.