Bower is a pain w/customization

[grayghostvisuals]

Love this, but one problem I have is bower. Bower is very powerful, but for things u really won't touch.

Tried using this project on bower, but wanted to change a whole load of stuff. Padding on the inner modal div, border color, width, breakpoints etc.

Maybe one of these days we can actually take advantage of a better package mgt. system. I just don't think we are there yet with them.

[drublic]

Thanks so much for bringing up this issue. With #58 we will be trying to make the modal more customizable and make it easier to use it with Bower.

We could use some help with defining the customizable variables in Sass – so if you are up for it we would be very thankful.

[grayghostvisuals]

Yeah I'm down. What I am doing right now with my project Typeplate (also on bower) is taking advantage of a separate var file. The main project file contains vars with Sass' !default flag. I don't know how I still feel about this method though :\ It really blows that bower rewrites the file when you update it.

Where do u want me to start? Don't wanna begin on something someone else is doing or does not agree with.

[drublic]

Thanks for your ideas.

I am not sure where we should start with this.
Maybe a structure like this would be great:

|-- components
   |-- css-modal
      |-- _modal-config.scss
      |-- _modal-core.scss
      |-- _modal-theme.scss
      |-- modal.scss
|-- scss
   |-- _modal-config.scss
   |-- main.scss

While _modal-config.scss in css-modal (Bower component) holds all of the modal's default configuration, maybe with a !default directive (might be needed). The _modal-config.scss file in scss holds all the custom overwrites we need. We could include a template for this in the package too.

main.scss would have the following inclusions:

@import 'modal-config';
@import '../components/css-modal/modal';

All configuration in the local file overwrites the global defaults.

What do you think? Does this make sense?

[grayghostvisuals]

Yup makes sense. Kind of the only way around this atm w/Bower. Users will have to duplicate the modal-config file and manually bring it over into their Sass folder if they want customization.

I can start on creating the config files. What's the workflow you want? Thinking a branch called development that pulls in branches from other contributors might be a good flow.

[drublic]

We use "v1.0.0" as our "development" branch atm. It would be awesome if you could create a branch from there and use the existing work in #58. You can then do a PR against v1.0.0 and we will review from there. Sounds good?

[grayghostvisuals]

yup that works.

[grayghostvisuals]

@drublic Can u explain briefly on your build process with the v1.0.0 branch? Seems like we can also tackle a good contributing doc from this discussion.

[drublic]

I've added a little bit of contribution guidelines in CONTRIBUTE.md. Which information is missing?

[grayghostvisuals]

@drublic

Very, very minor as of right now…

1. npm install for fresh projects
2. What current version of Sass you're using

[drublic]

I've updated the CONTRIBUTE.md file. Thanks for the discussion and your ideas. Was applied in #73.