"Nightly" versions of plugins and/or preset-env

[romainmenke]

Proposal to add "Nightly" versions of plugins and/or preset-env

Issue/Challenge

When stage 0 features are implemented in browsers we need to rework the plugin.
This is almost always a breaking change for both the plugin and postcss-preset-env.

The same can happen if a spec is changed or amended.

Examples

:has pseudo

#101

This is now implemented in Safari Preview.
So people are starting to use it more and finally have another implementation they can compare with.

I would like us to be able to iterate quickly along side Safari Preview and get user feedback on our implementation.

This means frequent changes and some might be breaking.

Using CSS variables for postcss-logical

#91

This is a major change and could potentially resolve a whole range of issues.
It does negatively effect older browsers and I don't want to ship this if users are not ready.

Although there is a fallback for older browsers I still don't want to make any choices here that would lock us in later. Rolling the update back would another breaking change.

Getting user feedback would tell us if it's as good as I hope it is, allowing us to better judge the tradeoff.

css-color-4

#70

This is a very large change and addition.
At the moment it is starting to feel too large to properly review.

Being able to merge and ship this in pieces would be better for code quality.

Proposal

Instead of updating existing plugins we create plugins for "nightly" versions.
These do not live on another branch, just a different directory.

plugins/
plugins/postcss-logical
plugins/...

plugins-nightly/
plugins-nightly/postcss-logical
plugins-nightly/...

A variation of postcss-preset-env would be created.
This would only contain the "nightly" versions (if one exists).

By default all features would be disabled and users are required to turn them on.
This is different from postcss-preset-env were features are enabled based on stage and browser lists with a manual override.

This difference makes it easier to use a nightly version of a single plugin and let the rest be handled by the regular postcss-preset-env.

My goal is to have a space were we can iterate quickly and get feedback without causing disruption in postcss-preset-env.

This could also be done in different repo's by multiple authors but I fear this will fracture the ecosystem as users will end up creating snowflake setups of different nightly versions and maybe even pin those versions.

Deprecation/Removal

Because of events like leftpad I would keep all nightly versions on npm even if they are no longer needed/maintained/...

Having them all under the @csstools org also helps with this as no one else can claim packages in this namespace.

In the code base we would move over the changes to the regular version and then remove the folder. If we need another nightly for the same plugin we would start by duplicating the plugin and renaming it.

Usage

plugins: [
  postcssPresetEnv({
    stage: 0,
    features: {
      'postcss-logical': false
    }
  }),
  postcssPresetEnvNightly({
    features: {
      'postcss-logical': true
    }
  }),

Naming

This will need some bikeshedding, but could be something in this trend :

• nightly
• alpha
• unstable
• experimental

[Antonio-Laguna]

@romainmenke thanks as usual for your thoughts and wording this out. I might be too naive but what do you envision differently from preset-env that would live on preset-env-nightly? I reckon just disabling it on postcss-preset-env and chaining it should be enough?

Also not sure about a different directory, we could end up in a situation in which we only want to be releasing experimental which, eventually, will become "stable" and keep the other one around for maintenance fixes. Merging from experimental branch to main will probably always be a "major" release.

Thoughts on this?

---

My 2 cents is to go with experimental

[romainmenke]

I might be too naive but what do you envision differently from preset-env that would live on preset-env-nightly? I reckon just disabling it on postcss-preset-env and chaining it should be enough?

I would like to have a real separation between the two.
I also considered flags or options in plugins and postcss-preset-env for a bit but if we change any user facing API it's a breaking change. So having experimental stuff in the regular plugins would cause a lot of major version bumps when we change or remove them again.

postcss-preset-env-nightly would just act as a plugin bundle.
But maybe it is more hassle than it's worth and it's better not to do this.

Also not sure about a different directory, we could end up in a situation in which we only want to be releasing experimental which, eventually, will become "stable" and keep the other one around for maintenance fixes. Merging from experimental branch to main will probably always be a "major" release.

I am not a fan of branches for things that are long lived as these create clutter and confusion.
We might end up with multiple experimental branches for a single plugin with no one remembering which one is the latest or most correct.

I would like main to be equal to npm as it is a much simpler mental model.

we could end up in a situation in which we only want to be releasing experimental which, eventually, will become "stable"

This is something to consider!
We don't currently do this in any way.

But this is also were a flag or option would be appropriate.
After an implementation matures as an "experimental" plugin we can hide the old implementation behind a plugin option.

---

experimental works for me!

It doesn't have any other concepts attached to it that conflict with what I mean here.

[romainmenke]

small update

Moving forward we are going to try "experimental" plugin releases.

These can be found here : https://github.com/csstools/postcss-plugins/tree/main/experimental#readme

We'll see how this goes and adjust were needed.

At the moment I am taking this slow.
I prefer having a single plugin go through an entire cycle from experiment to a major release before adding more in this way.