Running 'foundation build' results in error at 'sass' step

Hi!

I’m attempting to use Foundation for Emails, and I seem to be running into issues when CSS is about to be inlined.

Things seems to go okay when running ‘foundation watch’: my web browser starts up, and I can see the default pages that are provided with a new project.

However, when I try to run ‘foundation build’, the ‘sass’ step “errors” at ‘gulp-uncss’, and I have no clue how to troubleshoot this issue.

I’ve searched this forum, the GitHub issues (including closed issues), and searched StackOverflow. There seem to be similar issues, but they mostly seem to have to do with certain advanced features and/or inavertent of diacritic characters.

Some information:

$ lsb_release --all --short
No LSB modules are available.
Debian
Debian GNU/Linux 10 (buster)
10
buster
$ nodejs -v
v10.22.0
$ npm -v
6.14.6
$ foundation -v
Foundation CLI version 2.2.6

Console output of ‘foundation build’:

$ foundation build

> foundation-emails-template@1.0.0 build /home/user/test/test
> gulp --production

[16:43:26] Requiring external module babel-register
[16:43:29] Using gulpfile ~/test/test/gulpfile.babel.js
[16:43:29] Starting 'default'...
[16:43:29] Starting 'build'...
[16:43:29] Starting 'clean'...
[16:43:29] Finished 'clean' after 14 ms
[16:43:29] Starting 'pages'...
[16:43:30] Finished 'pages' after 804 ms
[16:43:30] Starting 'sass'...
Auto configuration failed
[16:43:31] 'sass' errored after 971 ms
[16:43:31] Error in plugin 'gulp-uncss'
Message:
    Auto configuration failed

Details:
    domainEmitter: [object Object]
    domain: [object Object]
    domainThrown: false
[16:43:31] 'build' errored after 1.79 s
[16:43:31] 'default' errored after 1.8 s
Error: foundation-emails-template@1.0.0 build: `gulp --production`
Exit status 1
    at EventEmitter.<anonymous> (/usr/lib/node_modules/foundation-cli/node_modules/npm/lib/utils/lifecycle.js:217:16)
    at EventEmitter.emit (events.js:198:13)
    at ChildProcess.<anonymous> (/usr/lib/node_modules/foundation-cli/node_modules/npm/lib/utils/spawn.js:24:14)
    at ChildProcess.emit (events.js:198:13)
    at maybeClose (internal/child_process.js:982:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:259:5)

The error message of step ‘sass’, plugin ‘gulp-uncss’, says:
Auto configuration failed
…and that’s basically where I’m stuck :slight_smile:

Does anyone know how I could proceed troubleshooting? Thanks!

Can you search for the error message in the node_modules folder? I’m not sure where exactly it comes from.
So far I can not find the error message in the foundation-emails-template folders using grep.
Same for foundation-cli.

1 Like

Hi @DanielRuf,

Thanks for the pointer; I’ve been able to solve the issue now - thank you!

Can you search for the error message in the node_modules folder? I’m not sure where exactly it comes from.

In my project directory:

$ grep -rn "Auto configuration failed"
Binary file node_modules/gulp-uncss/node_modules/uncss/node_modules/phridge/node_modules/phantomjs-prebuilt/lib/phantom/bin/phantomjs matches

So, that would make it a PhantomJS issue. Trying to manually run the phantomjs executable yields:

$ cd node_modules/gulp-uncss/node_modules/uncss/node_modules/phridge/node_modules/phantomjs-prebuilt/lib/phantom/bin/
$ ./phantomjs 
Auto configuration failed
139745067712128:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:185:filename(libssl_conf.so): libssl_conf.so: cannot open shared object file: No such file or directory
139745067712128:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:244:
139745067712128:error:0E07506E:configuration file routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:285:module=ssl_conf, path=ssl_conf
139745067712128:error:0E076071:configuration file routines:MODULE_RUN:unknown module name:conf_mod.c:222:module=ssl_conf

That level of verbosity helped; it seems that PhantomJS is unable to parse Debian 10’s OpenSSL 1.1.1d configuration. Others projects using PhantomJS seem to be running into similar issues:
https://github.com/wch/webshot/issues/90

The work around I’m using now is to set environment variable OPENSSL_CONF to an arbitrary value other than /etc/ssl/openssl.cnf. One example that leads to success for this use case:

OPENSSL_CONF=/tmp/ ./phantomjs
phantomjs>

So, in order to successfully run foundation build:

$ OPENSSL_CONF=/tmp/ foundation build

> foundation-emails-template@1.0.0 build /home/user/test/test
> gulp --production

[08:40:33] Requiring external module babel-register
[08:40:37] Using gulpfile ~/test/test/gulpfile.babel.js
[08:40:37] Starting 'default'...
[08:40:37] Starting 'build'...
[08:40:37] Starting 'clean'...
[08:40:37] Finished 'clean' after 12 ms
[08:40:37] Starting 'pages'...
[08:40:37] Finished 'pages' after 762 ms
[08:40:37] Starting 'sass'...
[08:40:39] Finished 'sass' after 1.6 s
[08:40:39] Starting 'images'...
[08:40:39] gulp-imagemin: Minified 0 images
[08:40:39] Finished 'images' after 259 ms
[08:40:39] Starting 'inline'...
[08:40:42] Finished 'inline' after 2.23 s
[08:40:42] Finished 'build' after 4.87 s
[08:40:42] Starting 'server'...
[08:40:42] Finished 'server' after 58 ms
[08:40:42] Starting 'watch'...
[Browsersync] Access URLs:
 ---------------------------------------
       Local: http://localhost:3000
    External: http://192.168.122.36:3000
 ---------------------------------------
          UI: http://localhost:3001
 UI External: http://localhost:3001
 ---------------------------------------
[Browsersync] Serving files from: dist

Success! :smiley:

For others considering using this work around:
please do not set the environment variable OPENSSL_CONF systemwide (e.g. export it in your .profile or .bashrc/.zshrc); you may end up inadvertently make other projects use less secure OpenSSL defaults that way.

@DanielRuf: Once more: many thanks - for your help, and for Foundation for Emails!

Thanks for your the detailed explanation and the time you took to debug this.
I think that will help others too.

Probably I did not find it in my node_modules because phantomjs may have been globally installed on my laptops.