Breaking changes for next major

[xzyfer]

Current WIP: #2312

We have been planning to release node-sass@v5 with LibSass 3.5.0 stable when it's ready. With a 5.0 milestone on the horizon we want to take note of the breaking changes we're planning to make.

This is living, and incomplete. Please subscribe for updates.

Node versions support

Moving forward we'll only be actively supporting active LTS and current Node versions. In practical terms this means Node 610+.

• supporting old versions of Node and npm is a significant maintenance burden
• older versions of npm are notoriously troublesome when it comes to native modules - it's becoming impractical, and sometimes even unsafe, to continue using old packages.

See #2290
See #2286
See #2257
See #2170
See #2256
See #2205
See #2288
...the list goes on

Switch watcher to node-chokidar

Why? Because Gaze in docker and various virtual machines uses a lot of resources whereas chokidar does not. Read about the advantages of chokidar

[...] in docker for mac you will get really high CPU usage with com.docker.hyperkit and com.docker.osxfs (I've seen reports of up to 300%).

See #2208

Compile on watch by default

When using the watch flag we should do a compilation before watching.
This becoming the expected behaviour in JS (see webpack).

See #2300
See #1973
See #1369
See #1742

Stop watching .css files

A LibSass has a feature/bug that allows it to @import .css files.
This means our watcher must also watch for .css files.
This can cause infinite loops if the input and out directories are the same.
LibSass is deprecating this behaviour.

See sass/libsass#2611
See #2184
See #2006
See #1933
See #1925
See #1867
See #1845

Don't fail installation on unsupported environments

In order to reduce issues about installation issues we failed the installation if we detected an environment we didn't provide binaries for.

This had the intended affect, but also had some unfortunate side-effects

• difficult or impossible to install on environments that could fallback to local compilation i.e. arm, electron
• required a version bump when new version of node landed
• couldn't back port support for new Node versions

In v5 we should still produce an informative error, but allow the installation to continue.

[nschonni]

For the node support version here is my proposal. Since Node publishes their LTS and dev branch timeline on https://github.com/nodejs/Release#lts_schedule

• LTS minus 2 months, start spitting a warning on install warning that support is running out
• LTS expired + 2 months, only allow install through a flag(--unsupporting-lts-bypass?), but warn no issues will be fixed
• Dev/Odd number branches are no longer installable after new LTS branch date
• Add curl/wget commands to the output for those that just can't/won't update

Not suggesting that binaries are removed after the LTS expiry, just that our install/download will error out and tell users to upgrade. This may change a little if/when WebAssembly is available, but I'm not going to assume that's a 5.x thing.

[nschonni]

I think dropping/simplifying the binary options would also be a good idea. Just replace them with some curl/wget commands. Alternately, some instructions on symlinking for those that want the old site-layout style.

[nschonni]

Maybe take a look at node-pre-gyp again as it looks like someone setup a GH releases piece https://github.com/bchr02/node-pre-gyp-github

[nschonni]

Looks like node-pre-gyp doesn't have download caching right now, but there is a PR pending mapbox/node-pre-gyp#272

[bruce-one]

Just fyi, this repo supports node-pre-gyp for node-sass and publishes to github: https://github.com/bruce-one/node-sass (the binaries can be seen on the releases page). Eg npm i bruce-one/node-sass with node 8 installs using the binaries off github for me.

Just if of interest (never quite got round to making a PR :-s it's not very complicated though :-) also, fyi, the commit history is a mess because of trying to force travis builds. The diff isn't all that much.)

[nschonni]

@bruce-one thanks! looks good, think we'd clean out a bunch of our custom SASS_BINARY stuff if we implement that. Also could rename the binding.node to the more standard node_sass.binding too. I won't do my own PR for now, but I'll ping you when we're ready for this 😄

[xzyfer]

We considered pre gyp for a long time but at the time it only supported Windows/Linux/OSX builds. It was non-trival to add freebsd and might have tied outlet hands with alpine, electron and potentially and support. Maybe that has changed now. It's been over a year since we've looked seriously

…

On 2 Nov. 2017 4:02 pm, "Nick Schonning" ***@***.***> wrote: @bruce-one <https://github.com/bruce-one> thanks! looks good, think we'd clean out a bunch of our custom SASS_BINARY stuff if we implement that. Also could rename the binding.node to the more standard node_sass.binding too. I won't do my own PR for now, but I'll ping you when we're ready for this 😄 — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#2111 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjZWAmjlx--vkrmDq4dL1XiWC8QRDm9ks5syUzygaJpZM4Pv8yX> .

[xzyfer]

Platform support has been improved, but still doesn't match our supported platforms. Looks like there's also not support for electron or musl which is a bummer.

--target_platform=win32: Pass the target platform and override the host platform. Valid values are linux, darwin, win32, sunos, freebsd, openbsd, and aix.

Maybe we could look at PRing musl.

[nschonni]

https://github.com/mapbox/node-pre-gyp#versioning

libc matches require('detect-libc').family like glibc or musl unless the user passes the --target_libc option to override.

[bruce-one]

I believe Electron support is handled via the runtime property rather than platform, and from what I know node-pre-gyp is used by Electron projects.

[xzyfer]

Awesome. Let's take a look! I only skimmed the docs over breakfast.

…

On 3 Nov. 2017 8:23 am, "bruce-one" ***@***.***> wrote: I believe Electron support is handled via the runtime property rather than platform, and from what I know node-pre-gyp is used by Electron projects. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#2111 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjZWEbXJoiA7eQmSsPVTegS-9ThpllSks5syjLdgaJpZM4Pv8yX> .