update postcss to version 7 #231
Conversation
|
Also adjust travis build. Node 4 is no longer supported: https://github.com/postcss/postcss/releases/tag/7.0.0 |
|
This is so necessary. This module – on its own – pulls in two distinct versions of It's directly & solely responsible for
Then In any event No wonder If you don't care about this package anymore, please transfer it to someone who does. |
| "postcss-modules-local-by-default": "1.2.0", | ||
| "postcss-modules-scope": "1.1.0", | ||
| "postcss-modules-values": "1.3.0" | ||
| "postcss": "7.0.5", |
There was a problem hiding this comment.
I know this is not EECOLOR's fault – the PR is 1.5 years old – but pinning to 7.0.5 would cause the same issue I've pointed out.
This should have always been a semver range.
| "postcss": "7.0.5", | |
| "postcss": "^7.0.0", |
There was a problem hiding this comment.
As a side note, some versions before 7.0.5 contained bugs that prevented stuff from working. It's too long ago to remember which ones. If you still want to go this route I would suggest ^7.0.5
There was a problem hiding this comment.
It does not matter. By specifying a semver range, any dependents will resolve the latest 7.x match.
In this case, everyone will be downloading 7.0.32 as that's currently the latest.
Pinning a specific version is a large part of what got poatcss-modules into this mess.
There was a problem hiding this comment.
While you are right in most cases, if a user has 7.0.3 for example and he adds this module, things will break.
That said, practically I think it's fine to use ^7.0.0 because 7.0.5 was released long enough ago. The chance a user has a lower than 7.0.5 is very slim.
For these types of libraries I think I would even move the dependency to the peerDependencies.
There was a problem hiding this comment.
Agreed, although I'm not sure if yarn@2 and pnpm provision peerDep access correctly. I assume they do, but not 100% sure.
In your example, if the user already had 7.0.3 locally, they'd at least keep that. They certainly wouldn't do back down to 7.0.0. But in 99% of cases, the fresh install of this module (assuming it ever gets out) triggers a refresh of its dependencies, resolving to the latest version that matches the specified range.
|
@lukeed Please read these comments: madyankin/postcss-modules#70 (comment) |
|
I'm just looking to get things fixed as quickly and simply as possible. I don't think it's wise to hold out/dream for plugin rewrites when something like dependency resolution has been a blocker/unmaintained for ~2 years |
|
That is exactly the reason why we stepped away from using this module and just used the separate underlying modules that do the actual work. |
|
who holds the keys to this package? @alexander-akait do you have access to this? most bundle css-modules support outside of webpack is using this incredibly outdated tool. It deserves love. I would be happy to help update and maintain it if someone who has access could please hand over the keys 🙏 css-modules is too pervasive to be abandonware and i'm happy to help! cc @markdalgleish @geelen |
|
@jquense In hindsight using this specific module proved to cause problems. That is why we now embrace the move to the underlying libraries. If you do want to try and create a package like this, you might find some inspiration here: https://github.com/kaliberjs/build/blob/master/library/webpack-loaders/css-loader.js |
|
How I can help? |
please note that you need to set the correct version and names for:
The tests are failing. In some case it might be because they reference a local version of the dependency. In others the behavior of the dependency is changed. I lack domain knowledge to determine if the changes are ok.
css-modules/postcss-modules-extract-imports#150
css-modules/postcss-icss-selectors#125
css-modules/postcss-icss-composes#169
css-modules/postcss-icss-values#113