Breaking changes for next major #2111
Comments
|
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
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. |
|
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. |
|
Maybe take a look at |
|
Looks like node-pre-gyp doesn't have download caching right now, but there is a PR pending mapbox/node-pre-gyp#272 |
|
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 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.) |
|
@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 |
|
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>
.
|
|
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.
Maybe we could look at PRing musl. |
|
https://github.com/mapbox/node-pre-gyp#versioning
|
|
I believe Electron support is handled via the |
|
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>
.
|
|
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. |
|
@surfaceowl I would like to remove request completely and use |
|
@nschonni It is. Locked to 2.81.0. |
|
@nschonni -- that would help. Even though |
|
Update the issue description with additional changes in v5. |
|
Work on this has begin in #2312 |
|
@bruce-one we've created the |
|
I'm growing concerned that the Active LTS and Current support target may be
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
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. ReferenceYou 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
}
}
}
}
}
} |
|
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:
I'll leave the decision-making to others 😄 |
|
are there any plans to drop node-gyp for cmake-js (or other) eliminating the requirement of python 2.7 to be installed? |
|
No
…On Tue., 15 Jan. 2019, 10:15 pm Victoria French ***@***.*** wrote:
are there any plans to drop node-gyp for cmake-js (or other) eliminating
the requirement of python 2.7 to be installed?
—
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/AAjZWHL3Vy_8MvrYYjEfBzIbpMJlEiALks5vDsNlgaJpZM4Pv8yX>
.
|
|
Is there a release date for version 5? |
|
the description ^^ and the TROUBLESHOOTING.md file still say
As of 21 October 2019, Node 8 is the oldest LTS. Does this mean we drop node 6? That would mean finally dropping CentOS 5 \o/ (despite what the release page says, node 7 does not work on CentOS5). Do we drop node 6? |
|
We're likely to only support node >= 10. This will allow us to seriously
consider n-api again.
…On Mon, 21 Oct 2019, 8:03 pm Marcin Cieślak, ***@***.***> wrote:
the description ^^ and the README.md file still say
As of ***@***.*** only Node 6 and above will be officially supported.
As of 21 October 2019, Node 8 is the oldest LTS. Does this mean we drop
node 6? That would mean finally dropping CentOS 5 \o/ (despite what the
release page says, node 7 does not work on CentOS5).
Do we drop node 6?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#2111?email_source=notifications&email_token=AAENSWHPXPIYVOVUPWEQB5TQPVV55A5CNFSM4D57ZSL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBZTHHY#issuecomment-544420767>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAENSWCCP3F4FNQZKQGKXN3QPVV55ANCNFSM4D57ZSLQ>
.
|
|
Node 10 isn’t universally available on all cloud platforms yet. Even in google it is only available as an unsupported beta. Only certain services on AWS have support. Removing Node 8 while it is in LTS could cause an uproar. |
|
I have went through a lot of issues on our tracker during last few days and I have my doubts about watcher changes. I suspect our watcher support in node-sass CLI is pretty broken and replacing the watcher engine will not help. I am not sure I can attribute any of the open issues to gaze, most of them are related to the ways we expand the list of the watched files. I'll try to do something about it but I suspect it is too much work to fit into the nearest breaking release. |
The EOL for 8 is in December https://github.com/nodejs/release |
Eh, didn't know that. I retract my objection then. |
Yes, it's a mess we should drop ASAP. What does not help is that our release binding file name is not what we import, maybe we should change this somehow? |
|
Stats for version 4.12.0 (available since April 2018, using @realityking's gist, updated)
|
I want to use node-pre-gyp, but losing the caching we do here is a problem. I don't know if there is a consistent story for caching anywhere for the pre-built addi-ins (still) |
|
In v5, will anything change for the |
No changes in the API here. |
|
I have updated the libsass version on branch v5 to 3.6.3. #2859 |
|
@nschonni --- |
|
when will V5 be released? |
This comment has been minimized.
This comment has been minimized.
nschonni
changed the title
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+.See #2290
See #2286
See #2257
See #2170
See #2256
See #2205
See #2288
...the list goes on
Switch watcher to node-chokidar
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
In v5 we should still produce an informative error, but allow the installation to continue.
The text was updated successfully, but these errors were encountered: