About plugin naming/scoping for new features

[romainmenke]

see : #70

I would really like to add full support for css-color-4 and css-color-5 (depending on spec status).

Had some thoughts and questions and want to make the right compromise.

---

Context :

• postcss-lab-function also includes lab(...) and lch(...)
• postcss-color-functional-notation covers rgb(0 0 0) -> rgb(0, 0, 0)

Things I think are important :

1. Users that include packages directly and not via preset-env should easily understand the scope of a plugin by the name.
2. Too many individual packages results in too many chores when releasing.
3. We can't (easily) deprecate/rename existing packages.

---

Specific example

This makes it non-trivial to decide on where to add features like :

• hwb(...)
• hsl(...)
• oklab(...)
• oklch(...)
• ...

Overloading postcss-lab-function even more is possible but would make it harder for users to know what the package does.

Alternatively a new package could cover all css color functions and include the functionality of postcss-lab-function as a dependency? (might conflict with current workspaces setup, need to test this)

Any thoughts or ideas here?

---

What I observe in current package naming/scoping

Some packages are really tiny (rebeccapurple) and others are a collection of transforms (logical)

Personally I lean towards creating only larger packages that don't focus on a single transform.
They can still start small but have a predefined larger scope.

This would make it easier to add new transforms in an existing package.

• single transform : postcss-lab-function
• larger scope : postcss-color-functions

New functions like oklab would still fit the larger scope defined for postcss-color-functions

---

Regularly regrouping and naming the biggest hurdles / largest chores is important here.
More packages means more work and the mono repo helps a lot, but it doesn't solve every maintenance challenge.

If we often point out what is holding is back in some area's we can start thinking of ways to improve.

---

I also want to avoid getting slowed down by naming things.
Which is something I now experience :)

Not having a natural place to add hwb and hsl is a bigger hurdle than writing the actual transform.

Having good guidelines would help :)

[Antonio-Laguna]

I think it all comes down to specs. rebeccapurple is a minor dent of color 4 but all of these plugins are part of that larger spec in one way or another.

If we go the route of postcss-color-functions, eventually we'd be deprecating postcss-lab-function since I think that's what you're hinting. It'd be breaking in the sense that if you had specific options for that plugin, they wouldn't work but it'd be mostly compatible. We can delay that until it's inevitable.

I know this probably won't help but I'm keen either way.

On one hand, I tend to go for a smaller, single-purpose package/function always. On the other hand though, if they're going to share a bunch of logic it'd make sense to group them and/or extract them into another smaller package that abstracts that up. It could also make sense to have a plugin pack for color-4.

I guess it comes down how specific the code is between hwb and hsl since I assume it's already taking shape in your mind/mental models.

[romainmenke]

Good to hear that you do not have any immediate concerns in creating more small packages :)

---

Specifically for postcss-lab-function I also had this idea after posting this.

postcss-lab-function :

• is moved to plugin-packs (or a new similar directory)
• becomes an empty shell
• imports postcss-color-functions and sets a flag onlyLabAndHcl: true
• can remain supported indefinitely

---

I would have to prototype this and check how much hassle different configurations are.

Smaller packages are definitely simpler from an npm/node standpoint as the dependency tree would be simpler. With many small packages postcss-color-functions would not even need to exist.

But in preset-env packages are mapped to css feature names to check support status.
This will start giving issues as multiple packages might cover a single feature name.

Also need to figure out a way to easily check the feature name in caniuse-lite.
MDN data (used by caniuse) is not always consistent in how they map features, sub features and comments with warnings.

[romainmenke]

Plugin scoping is defined by how features are grouped (or not) in MDN and caniuse data.
This is how preset-env knows which plugin is needed for a certain config.

So for future plugins we simply need to lookup how the feature is mapped in MDN/caniuse and follow there lead.