Why does `NoWorkResult` exist? about postcss

[ai]

If so, what is the canonical way to get the AST?

let root = postcss.parse(css, { from })

Were there real world performance issues before NoWorkResult was introduced?

Some users have very complex build pipeline and forget PostCSS inside (without ant plugins).

This optimization helps them to not parse CSS without a reason.

[romainmenke]

let root = postcss.parse(css, { from })

That seems to work in the most simplistic cases but it isn't the same as postcss().process(). It takes different arguments and has a different return type.

In postcss-import, for example, users can set custom syntaxes, pass extra plugins, ...
postcss.parse doesn't accept plugins or syntaxes.

We can add our own checks to switch between postcss.parse and postcss().process() depending on user input.
But then we are doing the same (but different) as NoWorkResult vs LazyResult. This also implies that we can again encounter other subtle differences.

Shouldn't there be a single API that works consistently regardless of the input and options?
One function that can take zero or more plugins, a custom or default syntax and always does consistent work.

---

Some users have very complex build pipeline and forget PostCSS inside (without ant plugins).
This optimization helps them to not parse CSS without a reason.

Has there been any real world measurements of the benefits of this optimization?
It's hard to make any judgements or estimates about this aspect in the abstract :)

[ai]

users can set custom syntaxes

You should use syntax like syntax.parse() instead of postcss.parse().

We can add our own checks to switch between postcss.parse and postcss().process() depending on user input.

I think it will be the best strategy here. postcss-import use case is very specific.

Has there been any real world measurements of the benefits of this optimization?

Of course. Bootstrap (real project is a few times bigger) parsing takes about 30 ms, about 1/3 of Autoprefixer time https://github.com/postcss/benchmark

So we save this time on every build for users who uses PostCSS without plugins.

[romainmenke]

Of course. Bootstrap (real project is a few times bigger) parsing takes about 30 ms, about 1/3 of Autoprefixer time https://github.com/postcss/benchmark

So we save this time on every build for users who uses PostCSS without plugins.

I meant real projects :)

Not theoretical gains but real projects where users have no other option but to keep PostCSS in their toolchain without any plugins.

I am assuming that users can either stop running PostCSS when it isn't needed or that they have some stack that doesn't give them this control.

So the edge case is :

• users who don't have control over their tool chain
• users who do have PostCSS in their tool chain
• users who do not have any PostCSS plugins or custom syntaxes
• users who have very large amounts of CSS.

This should be a fairly small group right?

Compared to all users of CSS who need to download, parse, evaluate the extra file :)

---

I think I understand the issue better now and why NoWorkResult exists.
I don't personally think it is the best solution to the underlying problem, but I also don't have a really good alternative.

I will continue to use a noop plugin to avoid NoWorkResult because it simply is the most reliable and simple way to make PostCSS do what I want it to. This is fine.

---

This issue is resolved and can be closed.

[ai]

Not theoretical gains but real projects where users have no other option but to keep PostCSS in their toolchain without any plugins.

It is mostly not a need by wrong config.

I understand that we should not sacrifice user-who-read-docs for a solving mistakes user-who-dont-read-docs. But I need a good reason for removing safe system for people who are amking mistakes.

[romainmenke]

But I need a good reason for removing safe system for people who are amking mistakes.

There isn't any.
Now that the system is there, it is a different tradeoff :)

To remove it we need to prove that is causing problems that can not be solve except by removing it.

Better to iterate on it and improve it :)