Foundation-sites: Refactor settings & import approach to allow dist/scss, better dependency management

[kball]

Reference: https://github.com/zurb/foundation-sites/pull/9478

@ncoden please add more details

---

Our current workaround to use SCSS dependencies has a lot of problems:

• Dependencies are pushed on Git.
• Dependencies versions are pinned.
• Internal files and relations of dependencies are assumed.
• It is difficult to partially import the components (have to import /vendor/... too).

The goal is to move our current SCSS architecture into a real SCSS library. It require to:

• Compile all SCSS files and dependencies into a ready-to-use dist file (it is what #9478 did).
• Provide an easy way to import dependencies like Eyeglass, for the user who wants to import partials.
• Make the setting file be imported _after_ Foundation, so do not generate components or variable automatically, and wait for the ZF mixins and functions to be called.

[rafibomb]

One thing that has confused and created challenges is how to update Foundation. 6.3 is a good example where the settings file is drastically different and without completely pasting in a new one over the old (which would wipe out your custom settings).

It would be nice if there was a way to check the defaults vs changes and apply the new variables into the project.

[kball]

I'd love it if when we restructured this, we could separate out the concept of the defaults needed to function from the values set by the user, so that in the case of an update like the above brand new variables don't need to be imported by the user into their project in order to upgrade.

[ncoden]

It already works like that. The default needed variables are defined in the files of each components. Foundation does not require settings.scss to compile. So the user can simple create its own empty setting files, and add in it the few changes ze needs.

Maybe we should add comments in settings.scss to explain that this file is useful when you needs to change most of the settings, but otherwise you should rather start with an empty setting file / delete everything ze doesn't need from this file.

[ncoden]

Also, because of it is a generated file, settings.scss should not be in scss/settings.scss but rather in dist/scss.

[oxyc]

Maybe we should add comments in settings.scss to explain that this file is useful when you needs to change most of the settings, but otherwise you should rather start with an empty setting file / delete everything ze doesn't need from this file.

For our foundation base themes, we've always included settings.scss with all variables commented out. Just throwing it out there as an idea–we like this approach as have all the variables at hand, while still being able to distinguish overrides from defaults.

[paxperscientiam]

@rafibomb

I liked what you suggested in post #6941

We'd be very interested in an automated task to add any missing variable to an existing _settings file and would love to hear more ideas on that.

Ideally, this hypothetical script would indicate deprecated variables as well.

[ncoden]

@paxperscientiam This is not really the subject of this issue.

[kobrix]

It seems obvious now I've looked more closely, but being a novice user I didn't understand until now that_settings.scss is really a bunch of overrides for the settings in the component files. My next attempt to solve the update problem was going to be to grab a vanilla copy of the settings file and write my overrides into app.scss, but now I see that that would needlessly add another layer of overrides.

It hadn't occurred to me that I could start from an empty settings file, so I tend to agree that it’s more of a documentation issue than something looking for a technical solution. Some words of explanation within the settings file would be useful, and the idea of commenting out the bulk of lines might also help indicate that Foundation will work quite happily without them.

I’ve found even the few comments in config.yml to be useful, so it doesn't have to be much.

[kball]

@zurb/yetinauts would really like to get a better solution to this for 6.4.

My current inclination is to move to having almost all settings commented out by default, with additional commenting & information about how to use. Anyone else feel opinionated?

[kball]

Unfortunately don't think we'll have time for this for 6.4, pushing to 6.5.

[colin-marshall]

@ncoden is this something we should get to by 6.5? @kball's solution to just have all the settings commented out seems simple enough.