Foundation 6.7.x triples build times

[aliciahubbard-ur]

What should happen?

6.7.x should have similar css build times to previous versions.
...

What happens instead?

The time it takes to build the css in my project tripled from 40s to 1 minute and 20+ seconds. This is not unique to my project's setup or my local environment: https://github.com/foundation/foundation-sites/discussions/12414
...

Possible Solution

This may be related to updates to support dart sass?

Test Case and/or Steps to Reproduce (for bugs)

Codepen and similar services don't allow you to run npm builds, so I can't attach a live example.

How to reproduce:

1. Have an environment setup that uses NPM to build the Foundation scss plus some custom scss. I have tired some different things and node version doesn't have more than a marginal impact, nor does the version of node-sass. Switching to dart sass (albeit without fixing all the warnings this generates, as I have a large code base with lots of scss built to run on node sass) makes the build time even slower. I also tried Foundation 6.8.1 with the required dart-sass, and that is no faster than 6.7.x w/ dart sass.
2. time scss builds on Foundation 6.6.3 vs 6.7.x

Your Environment

• Foundation version(s) used: 6.6.3, 6.7.x
• Browser(s) name and version(s): N/A
• Device, Operating System and version: 2023 M2 MacBook Pro, different OS versions

here is my package.json:
{ "scripts": { "//GENERAL": " --- GENERAL --- ", "build": "npm install && npm run fonts && npm run images-build && npm run css-build && npm run js-build", "clean": "rimraf ../../../dev/{fonts/*,css/*,js/*,img/jpg/*,img/png/*,img/svg/*}", "reinstall": "rimraf node_modules && npm install", "start": "npm install && npm run fonts && npm run images-build && npm run css-build && npm run watch", "watch": "run-p serve images-watch css-watch css-watch-global js-watch", "//FONTS": "--- FONTS ---", "fonts:dev": "node tasks/fonts.js dev", "fonts:dist": "node tasks/fonts.js dist", "fonts": "run-p fonts:dev fonts:dist", "//IMAGES": " --- IMAGES --- ", "images-build:jpg": "node tasks/images.js 'jpg'", "images-build:png": "node tasks/images.js 'png'", "images-build:svg": "node tasks/images.js 'svg'", "images-build": "run-p images-build:jpg images-build:png images-build:svg", "images-watch:jpg": "onchange -p 100 '../../img/jpg/**/*' -- npm run images-build:jpg", "images-watch:png": "onchange -p 100 '../../img/png/**/*' -- npm run images-build:png", "images-watch:svg": "onchange -p 100 '../../img/svg/**/*' -- npm run images-build:svg", "images-watch": "run-p images-watch:jpg images-watch:png images-watch:svg", "//SERVE": " --- SERVE --- ", "serve": "node tasks/serve.js", "//CSS": " --- CSS --- ", "css-build": "node tasks/sass.js 'expanded' && node tasks/sass.js 'compressed'", "css-watch": "onchange -p 100 './scss/**/*.scss' -- npm run css-build", "css-watch-global": "onchange -p 100 '../_global/scss/**/*.scss' -- npm run css-build", "//JS": " --- JS --- ", "js-build": "run-p webpack-build js-unpackaged-build", "js-watch": "run-p webpack-watch js-unpackaged-watch", "webpack-watch": "webpack --TARGET=WATCH --config webpack.config.js", "webpack-build": "webpack --TARGET=BUILD --config webpack.config.js", "js-unpackaged-watch": "node tasks/unpackagedJavascript.js 'expanded' && onchange -p 100 '../_global/_unpackaged_js/**/*.js' -- node tasks/unpackagedJavascript.js 'expanded'", "js-unpackaged-build": "node tasks/unpackagedJavascript.js 'expanded' && node tasks/unpackagedJavascript.js 'compressed'" }, "description": "", "dependencies": { "calendar-link": "^2.1.1", "foundation-datepicker": "^1.5.6", "@panzoom/panzoom": "^4.4.4", "js-image-zoom": "^0.7.0" }, "devDependencies": { "autoprefixer": "^8.4.1", "babel-cli": "^6.26.0", "babel-core": "^6.26.3", "babel-loader": "^7.1.4", "babel-plugin-syntax-dynamic-import": "^6.18.0", "babel-plugin-transform-object-rest-spread": "^6.26.0", "babel-preset-env": "^1.6.1", "browser-sync": "~2.23.6", "chalk": "^2.4.1", "es6-promise": "^4.2.4", "foundation-datepicker": "^1.5.6", "foundation-sites": "~6.7.5", "fs": "0.0.1-security", "imagemin": "^5.3.1", "imagemin-jpegtran": "^5.0.2", "imagemin-pngquant": "^5.1.0", "imagemin-svgo": "^6.0.0", "jquery": ">=3.6.0", "lodash": "^4.17.10", "lozad": "^1.7.0", "minimist": "^1.2.0", "mkdirp": "^0.5.1", "motion-ui": "~1.2.2", "ncp": "^2.0.0", "node-sass": "^4.9.0", "npm-run-all": "^4.1.5", "onchange": "^4.0.0", "path": "^0.12.7", "postcss": "^6.0.22", "rimraf": "^2.6.2", "ts-loader": "^4.1.0", "typescript": "^2.8.3", "uglify-js": "^3.6.0", "uglifyjs-webpack-plugin": "^1.2.5", "webpack": "~4.3.0", "webpack-cli": "^2.1.3", "what-input": "~4.1.3" } }

Checklist

• [ x] I have read and follow the CONTRIBUTING.md document.
• [ x] There are no other issues similar to this one.
• [ x] The issue title and template are correctly filled.

[nitrokevin]

One thing I've noticed that has an effect for me is the number of colors in foundation palette, I've got it down to 25s build time, though its not convenient because I need the colors in the palette

[aderowbotham]

I have just moved from an old setup where I was using grunt-sass, and on the same computer that was taking about 1.5 seconds. Now with Foundation 6.8.1 gulp-sass it is taking around 7 seconds

[ edit ] – actually a 2-3 seconds less than that. I realised that by default it includes all of foundation-xy-grid-classes, foundation-grid and foundation-flex-grid and only one should be picked

[redpop]

I have the same problem
with Foundation 6.8.1 (from version 6.7.0) it takes 16s and before with 6.6.3 it takes 5s

I have not yet discovered a workaround

[nitrokevin]

I just went back to an old project and was shocked how fast it was compiling, felt instantaneous compared what I have got used to

[javierm]

I've been debugging this issue, and can confirm that, at least in my project, the introduction of the divide function for Dart Sass compatibility in #12241 is the cause of the slow compiling times; in particular, its usage inside the nth-root function seems to be the critical one.

Since the nth-root function is only called by the pow function, I've found a workaround for Dart Sass which consists on overwriting the pow function. Unfortunately, it doesn't work for SassC/Libsass because the math.pow function isn't available in SassC/Libsass.

@use "sass:math";

@function pow($base, $exponent, $prec: 16) {
  @return math.pow($base, $exponent);
}

[redpop]

I found a workaround:

I am using Gulp v4 for the frontend build pipeline and have now switched to https://www.npmjs.com/package/gulp-sass because the npm page states the following:

Note: When using Dart Sass, synchronous rendering is twice as fast as asynchronous rendering. The Sass team is exploring ways to improve asynchronous rendering with Dart Sass, but for now, you will get the best performance from sass.sync(). If performance is critical, you can use node-sass instead, but bear in mind that node-sass may not support modern Sass features you rely on.

My Gulp task to create the CSS looks something like this - I have shortened the task to show only the key parts:

import dartSass from 'sass';
...
import gulp from 'gulp';
import gulpSass from 'gulp-sass';
...
import plugins from 'gulp-load-plugins';
...

const $ = plugins();
const sass = gulpSass(dartSass);

function stylesBuild(source, outputDirectory) {
    ...

    return gulp
        .src(`${config.PATH.src.styles}/` + source)
        .pipe($.sourcemaps.init())
        .pipe(
            sass
                .sync({
                    includePaths: config.PATH.inlcudePathsForSass,
                })
                .on('error', sass.logError),
        )
        .pipe($.postcss(postCssPlugins))
        ...
        .pipe($.if(!config.PRODUCTION, $.sourcemaps.write('.')))
        .pipe($.multiDest(outputDirectory))
        .pipe(browser.reload({ stream: true }));
}

export function stylesGlobal() {
    return stylesBuild('app.scss', [config.PATH.dist.css]);
}

There are more examples on the npm page. The trick is to use sass.sync(), and with that, I have achieved the original CSS build time again.

[joeworkman]

fixed in v6.9.0

[aliciahubbard-ur]

@joeworkman : when will 6.9.0 be available? It looks like it hasn't been released yet.

[joeworkman]

Today. I'm just combing through issues to find any more low hanging fruit.