# Salesforce Lightning Design System

August 12, 2020

Found an issue in the Salesforce Lightning Design System (SLDS) while using Windows. Technically you can bypass it with different approaches but I the following one is the best and easiest fix of all.

SO…

The problem is that if you try to build or do a full-start on Windows, it will fail.

After doing some investigations, I found the issue is currently on one particular function under /scripts/compile/helpers.js :

const webpackPath = prefix => filepath =>
path.join(prefix, filepath.replace(/^\.\//, '').concat('.js'));

That function will join current prefix (something like internal/chunked/showcase) with a filepath (something like ./ui/components/button-icons/bordered-transparent-container/example.jsx). The replace function will get that “./” and replace with nothing (or empty string), then we concat the js extension (“.js”) at the end, resulting in the following joined path: ”internal/chunked/showcase/ui/components/button-icons/bordered-transparent-container/example.jsx.js”.

THAT is what is supposed to happen, and I have checked, it works well in Mac machines, so technically should be the same in Unix/Linux machines.

NOW…

On Windows, path.join is messing up with what the SLDS is using the bundling process (internally they are using webpack, which kinda makes sense, but the minification process, called Terser, is messed up). In Windows, instead of having a path following the pattern “path/to/file/name” , the function “path.join” will return the path following this pattern “\path\to\file\name”. That pattern is passed to Terser and because ’’ is considered an escaped character, Terser will fail to locate the things.

And that’s the main problem.

HOWEVER…

A fix that we can use, and prevents Terser from failing is to rework the webpackPath function as follows:

  const webpackPath = prefix => filepath => {
const [_root, ...rest] = filepath.concat('.js').split('/');
return ${prefix}/${rest.join('/')};
}

Yes, I know. It might no look great but we are basically doing the same thing. Instead of relying on the “path.join” function, we are just concatenating prefix and the filepath as they should. Terser, is not complaining anymore and now slds can run the npm run full-start without issues.

With all this in mind, a worst problem arises:

Testing

Salesforce is a big corporation with lots of dev employees, and stillit seems that they only had 1 target platform: MacOS.

Maybe it’s just because their devs are used to have less issues if they use Mac machines instead of Windows ones.

And I have to be completely honest here, I have been on both sides of the spectrum. I had to deal in the past with a lot of issues on Windows. I just recently moved to Mac.

Not having tested this piece of software on other platforms reveals that even though unit tests, ci/cd, and other stuff is setup, the testers bypassed that. Leaving many user, and Windows devs out. That could mean less usage as some people will not be pleased to adopt something that, sure, it works, on some platforms.

As a dev, I understand the benefits that design systems provide, and they are great way to design reusable components prior to deploy them into the current website. It easier also to check behavior and different states, even though I don’t agree with how SLDS represent those. There is literaly no interactivity, only static representation of the states, so you can’t interact with the components. That’s not great.

Maybe they will take of that on their next release (if there is any).

Written by Iggy Pops - Ignacio Garcia Villanueva , a javascript journeyman rocking his way to the top of the JS world. You should follow him on Twitter... he is good!