Release 1.22.8 has a breaking change

[ghost]

v1.22.8 is a breaking change but released as a patch. dropped node 8 support.

[nex3]

Can you provide more detail? What exactly is the breaking change?

[ghost]

Drop support for Node Carbon (8.x), which doesn't support url.pathToFileURL.

dropping support for a node version is the change.

[nex3]

Won't Node 8.x just install the most recent compatible version of Dart Sass?

[ghost]

Nope. We have to manually specify the version.

We use yarn, and yarn blocks installation of incompatible modules https://yarnpkg.com/lang/en/docs/package-json/#toc-engines. So we won't be able to install at all.

[ghost]

the change should have gone into v2.0.0

[DRoet]

@nex3 release 1.22.8 breaks everyone with node < 10.12.0 since that is when url.pathToFileURL got released.

I'd agree that this change is semver major

[nex3]

Well, that's distressing news, to say the least. While we figure out what to do about it, I've unpublished version 1.22.8.

[nex3]

I've put out a pull-request for the Node.js preamble we use to add back the url.pathToFileURL workaround it used to have (mbullington/node_preamble.dart#17). Once that lands, I'll release a new 1.22.9 that uses it and supports Node 8.x.

Going forward, we'll avoid dropping support for Node versions that we already support as long as they're still in the long-term service window. Once they're out of that window, all bets are off—we need some flexibility to use new APIs without releasing a new major version, something we try to avoid doing unless we have major breaking language changes.

[ghost]

Closing the issue as v1.22.8 is unpublished. The same features were added back in v1.22.9 without dropping node 8 support.

thanks @nex3

[Turbo87]

we need some flexibility to use new APIs without releasing a new major version, something we try to avoid doing unless we have major breaking language changes.

I'm not sure I understand. what is wrong with releasing a new major version if you drop support for an older Node.js version?

[nex3]

Major version releases force a considerable amount of churn on downstream users, all of whom need to update their dependencies to the latest version. Because many users won't be on the latest version, future changes and bug fixes are likely to be picked up much less broadly, which in turn means that new features are harder to adopt in libraries that need to work for many users. This is a high price to pay, so we do it as little as we possibly can.

[Turbo87]

hmm I tend to agree generally, but IMHO it depends on the amount and complexities of the breaking changes. If it's literally just bumping the Node.js version support then the churn should be relatively small. Considering the amount of work that goes into figuring out why the app doesn't compile anymore after a sass patch version update, it might be better to just do the breaking change release.

In any case it would be useful to explicitly mention the Node.js support policy in https://github.com/sass/dart-sass#compatibility-policy so that depending projects can make sure to pin their sass dependencies if necessary.

[nex3]

In any case it would be useful to explicitly mention the Node.js support policy in https://github.com/sass/dart-sass#compatibility-policy so that depending projects can make sure to pin their sass dependencies if necessary.

That's a good idea.