Define structure

[perry]

@incuna/frontend How does this sound?

Have master as the base (lots of mixins, helpers, etc) and then have epatient, edetail, ... branches that are kept in sync with the core stuff in master, but has additional stuff on top of that?

I know that with bower you can install a git repo from a specific revision or a specific branch if you provide the zip url. Obviously edetails would need to be updated to use bower for this as jam is a javascript package manager, not a front-end package manager.

Any thoughts?

[grahamgilchrist]

Interesting idea. So you are proposing to package manage all our sass?

At the moment we use it as a starting point and then modify once we have set up the project? How would we deal with replacing the default sass if it was package managed?

The base eDetail sass is very different from web-based stuff, but I guess we'd have a main.sass which differed in each branch, and that would import the appropriate sass files for each project?

[pandalion]

I'd like to know the reasoning behind wanting to do this? Like, the issue with how it is now. Otherwise I'm not sure I see the benefit of package-managing Sass.. ? Esp when we change it so frequently.

Though actually - the helpers and mixins maybe yeah. Those things we only add to and don't edit. I see the benefit for those :)

[perry]

Resets, mixins, helpers. There's a few hundred lines of sass that we use in every single project, that in 99.99% of cases isn't ever modified. It doesn't make sense to, in effect, copy and paste this between between projects.

However, when we do modify/add to them (https://github.com/incuna/incuna-project/commits?author=perry), having it packaged and versioned makes the process infinitely easier.

[perry]

@grahamgilchrist there should be a fair bit of common ground between the web and edetail stuff. Worth looking in to.

[pandalion]

@perry Ah yes, it seems good for those things that we literally never touch and if we do it's for everything :) I was thinking structure etc.. This seems good!

I think we'd still have main.sass per project.. so we can edit it easily ?

[perry]

Yes. We'd probably expose the bower path to the compass add_import_path so we can import only the modules you wanted (exactly how it's done atm).

[pandalion]

I hope bower has one of these for its logo!

[perry]

@pandalion you're almost in luck...

http://bower.io/

[grahamgilchrist]

I'm not sure there is very much common ground between eDetailing and web projects. eDetailing has no reset, and only a few mixins for fonts etc. which are quite different to the web-based ones due to the way the iPad handles them.

I'm all for DRYing it out to a single package if there are significant similarities which can save us time later, but I think I still need convincing there are enough similarities and that this will save a lot of time over the existing process.

@perry How would this process work in a project. We'd use bower to install the base sass project when setting up the project, and then selectively import the 'sass library' files we wanted into our main.sass?

Having essentially a 'sass library' could be useful. I think the main thing that will be useful would be versioning, so that we could easily update the sass library mixins for a project without copying and pasting from the latest base project. We'd probably want the library sass files separate from other base styles though, as for eDetails i can definitely see a situation where you'd want to update the mixins, but not the base sass structure as it would break the project...

I suppose another useful thing for eDetails would be having separate sass packages to go with the jam packages. e.g. a styling package for forms, which could go with the jamjs forms package. These could then be imported in to the eDetail and very easily swapped for another companies form styles.

[henrahmagix]

eDetailing has no reset

@grahamgilchrist I think it should do, so we don't have any problems with layout between Desktop and iOS, which happens often. Also there are different user-agent defaults between Chrome and Safari, meaning some of us might be seeing things differently. I think a reset would be a very good idea, although it would be much smaller for eDetails than for websites.

Issue here https://github.com/incuna/edetail-project/issues/75

[grahamgilchrist]

@henrahmagix You are right, that would be useful.

Versioning our Sass 'library' I think would be useful. The thing I want to avoid is introducing problems/extra complication to the existing process, but I think this would probably help things overall. @perry makes a good point that we can include the lib sass using a compass paths hook and then we only need to selectively use the bits we want.