[preset-env] v8 scope - batch 1

[romainmenke]

refresh of all plugins with client side scripts

focussed on :

• code quality
• browser tests
• spec compliance

---

Plugins :

• css-blank-pseudo
• css-has-pseudo
• css-prefers-color-scheme
• postcss-focus-visible
• postcss-focus-within
• postcss-preset-env

With :has() support rolling out in multiple browsers the spec is settling.
We have kept tack of these changes in an experimental plugin.

The final issues seem to have been resolved and it should be ready to ship.

As this is a breaking change we want to also do some chores on related plugins.
Over the past few years these have accumulated some cruft.

This is scoped so that migrating to v8 of postcss-preset-env will only affect those users who enable client side polyfills.

[romainmenke]

@Antonio-Laguna is there anything you would like to add or omit from this?

[Antonio-Laguna]

@romainmenke is there any reason not to include logical and importFrom removal here ?

[romainmenke]

We can include more but this will make the upgrade path for users less clear.

I suspect that each breaking change only affects a small part of our users but each time in a big way.

Making it simple to determine if a change affects you and which steps to take might help adoption.

For us it will also make support a bit simpler.
If v8 includes all the breaking changes at once we will have to answer questions and follow up on potential bugs for a lot more plugins and use cases.

So future major versions might be :

• 9 : logical
• 10 : importFrom + general plugin options/config cleanup

---

Doing everything at once is also totally fine for me :)
As long as we can communicate clearly to users which steps they need to take to upgrade.

[Antonio-Laguna]

Given the amount of work and planning around each major version, and also the amount of overhead that creates on other libraries, I'm a bit torn here. I completely see your point and at the same time, I don't want to put too much strain or appear unstable. Given the number of weekly downloads, having semi-frequent major upgrades makes me wonder if that's the right path.

Sadly I don't have an answer here or a more solid decision and I'm rather full of doubts 😂

[romainmenke]

below some thoughts, not always structured

---

Part of my concern can be resolved with just really good migration docs :)
The Wiki might be a good place for this.

---

As a user of postcss-preset-env I want my projects to work the same before and after the major version bumps.

Verifying this and applying changes becomes more complex if we break more at once.

---

We have a multiple factors that cause breaking changes that are beyond our control.
The actual API of PostCSS Preset Env hasn't changed much if at all.

• node versions that are no longer supported
• PostCSS major versions
• spec changes

Becoming good at breaking changes will be valuable and if we get good at this people will trust that each major version was created carefully and doesn't have undocumented surprises

---

🤔 but maybe we need to just chose the "short pain".
Too many plugins have cruft, haven't kept up with the specs, or have side effects.

After an initial big break we can keep up with everything else in much smaller changes.

[Antonio-Laguna]

The short pain is exactly my point. It's always like a sigh of relief whenever I see that a breaking change is because it's dropping support for a version of Node that I'm no longer on but it becomes problematic if I start to see a migration plan.

I'd rather do it once than do it multiple times, especially when it comes to "spec compliance".

At the same time, given the amount of time and processes around it because we want to be extra sure that we make it right, hinders our efforts in any other area which means delaying efforts into new areas such as Colors or Values.

If we make a breaking change and keep pouring new features, it's a solid reason to change whereas if we just go and remove things it might not be worth investing in that.

Finally, any user can purposely disable a plugin and include the old plugin to keep behaviour, theoretically, right?

[romainmenke]

Finally, any user can purposely disable a plugin and include the old plugin to keep behaviour, theoretically, right?

Only while that old plugin works with whatever PostCSS version is being used.

---

At the same time, given the amount of time and processes around it because we want to be extra sure that we make it right, hinders our efforts in any other area which means delaying efforts into new areas such as Colors or Values.

This also highlights (again) the conflict between providing polyfills and prototyping potential future CSS :)

semver can not express : "this is a major bump, but only if you chose the bleeding edge, otherwise it is a patch"

beyond the scope of this issue, but something to keep in mind going forward.

---

So big fat breaking change?

I suggest we keep the current scope but rename it to v8 - batch 1

[Antonio-Laguna]

Ok, I'm cool with that, 🔨 time

[Antonio-Laguna]

The first batch has happened and it's now released as 8.0.0-alpha.0