9

We are a team of about 6 developers with heterogeneous setups (Windows 10, Ubuntu, macOS) and have started developing with React.

Scripting between Linux/macOS & Windows was a pain, so we decided to use Bash for Windows to run our builds. This works quite well once you've setup Bash correctly, and the integration with VS Code is great. But there is a big catch: whenever you want to update your project outside of Bash (with CMD or PowerShell), you're effectively switching your OS, and then you've got a nice error from node-sass saying that your environment has changed.

Since rebuilding node-sass simply never works, the only way we've found to get rid of this problem is deleting or renaming node_modules & running npm install again, but it's very time/resource consuming.

We've seen that it looks like there is a native js alternative but we'd like to see if there's anyone that has experienced the same & has found a suitable solution.

We really don't have massive SASS files, so we don't care so much about performance (which is the main point of doing it in C++ with libSass).

Note: We can't always use Bash on Windows because we have some messy Maven integration in some Java / React apps that runs npm builds and this will always be in Windows.

Leo Lozes
  • 1,358
  • 1
  • 15
  • 33
  • 1
    Just to share our "solution": we started using Material-UI and dropped SASS (not needed for the few lines of CSS we have after using the library). – Leo Lozes Nov 23 '17 at 10:16

2 Answers2

1

We use an Angular 6 frontend in our application and had the same problem. We solved it by checking in the needed binaries into the repository and used different Maven profiles (one for every environment/os, default is linux for our CI) to set the sass-binary-path to its environment specific binary. However, it only works if you have a build system capable of setting environment variables. Another caveat is that you have to manually update your binaries.

<properties>
    <sass.binary.path.base>${basedir}/node-sass-binaries/</sass.binary.path.base>
</properties>
...
<profile>
  <id>linux</id>
  <activation>
    <activeByDefault>true</activeByDefault>
  </activation>
  <properties>
    <sass.binary.path>${sass.binary.path.base}/linux-x64-64_binding.node</sass.binary.path>
  </properties>
</profile>
<profile>
  <id>windows</id>
  <properties>
    <sass.binary.path>${sass.binary.path.base}/win32-x64-64_binding.node</sass.binary.path>
  </properties>
</profile>
<profile>
  <id>mac</id>
  <properties>
    <sass.binary.path>${sass.binary.path.base}/darwin-x64-64_binding.node</sass.binary.path>
  </properties>
</profile>
dnl.re
  • 373
  • 6
  • 23
  • Nice, I didn't think of that! I just don't mark it as "solved" because for me the solution would be to have a maybe less-optimized-but-I-don't-care compiler that would work on every OS. But it's a valid solution in the meantime. – Leo Lozes Oct 29 '18 at 09:49
1

One option is to use some PostCSS plugins: PreCSS & postcss-preset-env. There is a good, brief article here for the transition.

I have not done so myself; but researching to do so for a large-ish project. I have seen a few projects that had SASS notation, then noticed they were using only PostCSS+plugins, avoiding the node-sass mess. Just passing along the info.

tomByrer
  • 1,105
  • 12
  • 21
  • 1
    Thanks for the info! We've ended up using JSS (https://cssinjs.org) because we're using material-ui and it works pretty well :) – Leo Lozes Feb 28 '19 at 07:43