Remove babel.

[XhmikosR]

I think we should revisit this @kristerkari now since stylelint v13.0.0 drops Node.js 8.x support

Fixes #400

[XhmikosR]

@kristerkari how do you want to proceed with this?

[kristerkari]

@XhmikosR We could start preparing a v4 release that removes Babel and drops some old stylelint versions at the same time.

[XhmikosR]

Sounds good to me. I will rebase this branch. We should also drop support for Node.js < 10 in another PR and update all devDependencies.

[kristerkari]

@XhmikosR could you please create a v4 branch for all the work that goes into it?

[XhmikosR]

@kristerkari done. I changed this PR's target branch to v4.

But it'd be nice if we focused on that and we didn't need to rebase it frequently.

[kristerkari]

Yeah, let's try to get v4 out fast.

[kristerkari]

Let's get this done finally!

[kristerkari]

@XhmikosR now that there is going to be a major release, we could drop support for some older stylelint versions at the same time. I'm again not sure what should be the oldest version that we should support.

[XhmikosR]

@kristerkari I'd just go with the latest version only. Otherwise things get complicated and we don't test with multiple stylelint versions. Although there's a workaround you could try in order to test multiple stylelint versions, npm package aliases, which requires npm >= 6.9.0.

[kristerkari]

I see it as a difficult decision that I've discussed before with you.

I understand that testing older stylelint versions can be tricky, but at the same time supporting only the latest stylelint version might mean that we unintentionally make it impossible for some users to use the latest version of stylelint-scss if they are unable to update their stylelint version to the latest one.

If we change the peer dependencies to support the latest version, the user will only get a warning, but if we would actually break the backwards compatibility, then the users will have a broken library.

That's the reason why I have tried to avoid making breaking changes to this library in the past.

[XhmikosR]

Well, you can try testing multiple stylelint versions with the method above :)

Personally, I'd rather keep it simple and make it a breaking change since the next version will be a major one. People can use an old version anyway. And worst case scenario, we branch off before the major changes to keep a 3.x branch if needed later.