Chore: Modernize Dependencies

[lukeed]

This package is seriously outdated, and it's causing a noticeable hiccup when installing postcss-modules. Analysis below:

This module – on its own – pulls in two distinct versions of postcss: graph

It's directly & solely responsible for [email protected] being loaded.
It shares responsibility for [email protected] with:

• [email protected] – (2.2.0 available)
• [email protected] – (3.0.2 available)
• [email protected] – (3.0.0 available)
• [email protected] – (2.0.0 available)

Then postcss-modules, a popular dependent of this package, requires [email protected] – as it should, since that's the latest.

In any event postcss-modules loads 49 packages total in its network. This css-modules-loader-core package is responsible for 38 of them.

This PR updates all dependencies to their latest semver ranges.
It also updates your devDependencies which were seriously outdated too.

It's actually pretty impressive that despite 5 dependencies loading new major versions, the only difference was with newline placements in the most complex test case. 👏

---

Closes #231, #234, #233, #24

[lukeed]

This was needed because Babel 6 (and thus 7) no longer transform to module.exports by default. So in order to maintain current API this plugin was needed.

[lukeed]

Only structure/formatting changes in this file. ESLint threw errors with the old config.

[lukeed]

The "prepublish" hook is deprecated

[lukeed]

This is all that changed given the new dependency set!

[lukeed]

Travis is failing because new Mocha/whatever doesn't run on Nodes 4 and 6.

I set this up to support a patch release – so that we can resolve this dependency hell ASAP.
However, if you plan on releasing this as a major, let's update (and define) the engines constraints to something more recent than 2016.

Please let me know which so that I can adjust the test runner accordingly.

[lukeed]

Sorry for pings, but this has been a problem for nearly 2 years. Please let me know how to next proceed.
If you have zero intention of moving forward, then please let me know as well so that I can make efforts in forking and replacing this npm module. Either way, we need to end this misery.

@evilebottnawi @geelen @joshgillies @joshwnj @markdalgleish @michael-ciniawsky @Outpunk @sokra @sullenor @TrySound

[madyankin]

Unfortunately, I only have permissions for the postcss-modules repo.

Actually, I'm quite frustrated because of the state of the CSS Modules family and thinking of rewriting postcss-modules to not use any deps.

It's much easier to maintain a library that doesn't depend on unmaintained libraries. But this is a big amount of work, and I don't use postcss-modules myself. So I'm not sure if I should rewrite or maintain it at all.

[lukeed]

@Outpunk Yes, my initial mission was to rebuild postcss-modules from scratch, but then I found that nearly all the problems stemmed from this package. Fixing it here is an easier, lower hanging fruit. Now that I've identified this as the problem, my "worst case scenario" is forking this and hoping to PR the fork into postcss-modules. I'd rather not, but will if needed.

Reworking postcss-modules to be slimmer and/or more future-proof can still be done (sounds interesting!) but this needs addressing now.

I'm not aware of permissions – I just pinged everyone in the css-modules org, sorry

[madyankin]

@lukeed let's do this another way — by copy-pasting the
css-modules-loader-core files into postcss-modules. This will allow to fix the problem fast and start gradual rewriting of the library

[madyankin]

@lukeed working on it madyankin/postcss-modules#108

[alexander-akait]

Agree, let's focus on postcss-modules, i think we should deprecate css-modules-loader-core

[lukeed]

Awesome :) thanks @Outpunk !