Closed mchadwickweb closed 2 years ago
This is my favourite PR. I'll test it on Monday but it would be cool if as many people as possible had a look.
Ace, just want to double check its still going to be possible to install the packages individually if needed. Eg there may be times when just the fonts and colours are needed without the huge grid import. I'm guessing this won't be an issue as they're still independent on npm? :)
@omidantilong so the thinking for that scenario would be you still install the one package. Even if you just need fonts. But as part of the build it will do two things:
foundations.css
So in the scenario you're talking about I see it being something like
npm install @coopdigital/foundations
then in your stylesheet
@import "@coopdigital/foundations/dist/vars/colors.css";
@import "@coopdigital/foundations/dist/typography/typography.css";
This would allow that gradual / partial adoption to avoid loads of unnecessary CSS in a project. You're right that the packages will still exist in npm, but they would be flagged as deprecated and point to the migration steps to this package.
I hope this answered your question!
+1 for making all the utilities !important
👍 I was trying to use a utility the other day to apply some spacing but it was being overridden by some application-level code that had a higher specificity.
As per this discussion:
https://github.com/coopdigital/coop-frontend/discussions/444
This PR adds a new package and build scripts for a combined foundations packages. There have been little to no changes in the code within the package. The goal here was to combine them, provide a clear import for consumers and to fix cascade and specificity issues.
Combining packages into one
This packages aims to replace the following
and combine them into a single package called
Each package still retains its domain grouping within a sub-directory of the overall package. At the same time there have been some minor changes to the ordering, and splitting utilities and colours down further to allow better partial adoption if needed.
Changes to importing the code
Recommended: Importing everything
This is the easiest way to get everything you need.
Importing partials
If you only require partials of the foundations you can use the imports below. Make sure you keep the structure to ensure the cascade works.
The one place I changed code was to the utilities. They now have
!important
rules added to them so that they are immutable and can't be overridden easy by a more specific selector. A problem with the previous packages.Build scripts
I've added the foundation package specific build scripts into its package.json.
dist
There are two PostCSS builds here as we have to pass a different config file for PostCSS to the vars build. That way we can tell PostCSS to preserve the custom properties and custom media properties. The other build will strip them away to remove duplication.
I have then added a Lerna powered build command at root which triggers the package's build command seen above.