node-sass / Tickets / #2111 Breaking changes for version 5

Anonymous - 2017-10-06

assigned_to: xzyfer
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-10-06

assigned_to: saper
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-10-06

assigned_to: nschonni
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-10-06

Originally posted by: 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.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-10-06

Originally posted by: 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.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-11-02

Originally posted by: 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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-11-02

Originally posted by: nschonni

Looks like node-pre-gyp doesn't have download caching right now, but there is a PR pending https://github.com/mapbox/node-pre-gyp/pull/272

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-11-02

Originally posted by: 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.)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-11-02

Originally posted by: 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 😄

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-11-02

Originally posted by: 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" notifications@github.com 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
https://github.com/sass/node-sass/issues/2111#issuecomment-341318406,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWAmjlx--vkrmDq4dL1XiWC8QRDm9ks5syUzygaJpZM4Pv8yX
.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-11-02

Originally posted by: 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.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-11-02

Originally posted by: 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.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-11-02

Originally posted by: 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.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-11-02

Originally posted by: xzyfer

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

On 3 Nov. 2017 8:23 am, "bruce-one" notifications@github.com 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
https://github.com/sass/node-sass/issues/2111#issuecomment-341562534,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjZWEbXJoiA7eQmSsPVTegS-9ThpllSks5syjLdgaJpZM4Pv8yX
.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-12-13

Originally posted by: surfaceowl

Even though tunnel-agent is only used for internal build per this closed issue, it would be helpful if request were upgraded >2.83.0 in node-sass@v5.

Package vulnerability scanners don't differentiate between packages used only for install vs. runtime... which means we have to mentally keep track of 'this one is okay' for tunnel-agent under node-sass / requests.

Would be great if this dependency upgrade could be included.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-12-13

Originally posted by: nschonni

@surfaceowl I would like to remove request completely and use node-pre-gyp for 5, but I haven't looked to see if it is using request under the hood 😉

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-12-13

Originally posted by: realityking

@nschonni It is. Locked to 2.81.0.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2017-12-13

Originally posted by: surfaceowl

@nschonni -- that would help. Even though node-pre-gyp still uses request 2.81.0 it eliminates the current package vulnerability.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2018-03-24

Originally posted by: xzyfer

Update the issue description with additional changes in v5.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2018-04-04

Originally posted by: xzyfer

Work on this has begin in https://github.com/sass/node-sass/pull/2312

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2018-04-04

Originally posted by: nschonni

@bruce-one we've created the v5 branch now if you want to PR your node-pre-gyp stuff now ❤️

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anonymous - 2018-04-05

Originally posted by: xzyfer

I'm growing concerned that the Active LTS and Current support target may be
- complicated to communicate, and
- too aggressive

Looking at our release binary download stats, Node 4 (46) is getting a significant number of downloads.

We're forced to drop Node < 4 due to our dependencies. And we agree that using Node < 4 is unsafe and should be discouraged.

There are some Node milestones coming up in April
- Node 4 reaches EOL on the 30th, and
- Node 10 is due to be stable on the 24th

Given that we want to get a final 4.x release out with a LibSass bump. We should take this opportunity to add the Node 10 binaries, and monitor the release binary download numbers.

With any luck there will be a significant drop off in Node 4 installs. If not I would be more comfortable aiming for Node >= 4 support.

Reference

You can see the download stats with the following query in GitHub's GraphQL API explorer.

query { repository(owner: "sass", name: "node-sass") { releases(last: 5) { nodes { name, releaseAssets(first: 100) { nodes { name, downloadCount } } } } } }
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Originally posted by: realityking

I crunched the numbers for one release (4.7.2 to be exact) really quick. This might warrant digging a bit more (e.g. more release), so here's the code: https://gist.github.com/realityking/5f29d001ed96f1e9e6a318bb71122508

The result I got is this:

Release	Download Count	Percentage
Node 0.10.x	83,180	0.35%
Node 0.12.x	68,291	0.29%
io.js 1.x	51,943	0.22%
io.js 1.1.x	52,395	0.22%
io.js 2.x	52,064	0.22%
io.js 3.x	12,960	0.05%
Node.js 4.x	464,501	1.96%
Node.js 5.x	246,400	1.04%
Node.js 6.x	7,469,360	31.57%
Node.js 7.x	1,614,719	6.83%
Node.js 8.x	10,794,921	45.63%
Node.js 9.x	2,746,781	11.61%
Total	23,657,515	100%

I'll leave the decision-making to others 😄

Anonymous - 2018-06-05

Originally posted by: jeroensmit

Is there a release date/roadmap?
How can we as a community help to release v5 and with that help to remove the outdated (and vulnerable) dependencies?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Breaking changes for version 5

:rainbow: Node.js bindings to libsass

Milestone

Searches

Help

#2111 Breaking changes for version 5

Node versions support

Switch watcher to node-chokidar

Compile on watch by default

Stop watching .css files

Don't fail installation on unsupported environments

Related

Discussion

Reference