Option to disable javascript required features

[shrpne]

I want to disable all features which require javascript.
For now, I have to go through each plugin and check if it requires JS.
Then I have to specify each of them in the options.

It would be very helpful if:

• each feature which requires JS will have such note on the /features page
• there will be an option to disable all such features

Several other people wanting this:
csstools/postcss-preset-env#25 (comment)
csstools/postcss-preset-env#25 (comment)

[jonathantneal]

I want this, too. Additionally, I want these plugins to tell Webpack/Parcel/etc. to automatically bundle the required JS for me when these plugins are applied.

[wesgro]

Big plus 1 to this. Its not always possible to force consumers to install JS polyfills when creating a library.

[Antonio-Laguna]

@romainmenke while doing #115 thought about adding this too. However, I'm not sure if this makes sense at preset-env level or at the plugin level. On one hand, I think it's the responsibility of each plugin, on the other hand, I also think that it only makes sense at env level given that you might not even know you need to include a browser polyfill but you should if you're running the plugin in standalone mode.

If so, I think this merits yet another option which should be "silent" if you don't want this nor ' pluginIdHelp` to warn.

In any case, any thoughts?

How could we tackle this 👇

I want this, too. Additionally, I want these plugins to tell Webpack/Parcel/etc. to automatically bundle the required JS for me when these plugins are applied.

[romainmenke]

I think this is best done with a very explicit API.

{
  "stage": 0,
  "features": {},
  "browsers": "",
  "disableClientSidePolyfills": true
}

The name might need some bikeshedding but I like this to start from the issue : "I can't or don't want to polyfill the client".

---

Another concern is the current complexity in postcss-preset-env.
It already has very dense code that determines which plugins are enabled or disabled.

Maybe we can clean this up first before adding more config?

---

I want this, too. Additionally, I want these plugins to tell Webpack/Parcel/etc. to automatically bundle the required JS for me when these plugins are applied.

This is not possible :/

The best idea I had for this was to have plugins emit @import <client-side-polyfill> to a js file that users can determine.

The plugins would only add the @import statements if they actually transform something.
If no plugin transformed something the file would be empty (which afaik would be a valid .js file).

Users can then import this file where and how they like.

The issue with even this basic approach is that it requires tools and users to run processes in series. PostCSS has to run fully before any JS related task can even start.

Any decently optimised build script would run things in parallel or at least concurrently making this non-viable.

A more complex solution would be to create plugins for each bundler.
Users would have to configure these plugins to process their CSS fully just to detect which features are used. This would run PostCSS and a detection only variant of the plugins.

The plugins could then dynamically inject @import statements which the bundlers would pick up.

This approach is slow as CSS is processed twice.

It would also be nightmarishly complex as it would need to support all combinations in this matrix :

	fat CSS bundle	modular CSS	css-in-js
fat JS bundle
bundle splitting

I do not feel comfortable taking this on both in terms of complexity and for maintenance.

---

I think we best poor our efforts in documentation and sharing knowledge and avoid any convenience magic.

[romainmenke]

discussed with @Antonio-Laguna

Idea for some next major :

Disable these plugins by default and add a flag to enable them.

Making this explicit will make it much more likely that people who enable them also know that the client side polyfill is required and how to add these.

[romainmenke]

@shrpne @wesgro There is a new option enableClientSidePolyfills.

For now this defaults to true.
In a next major we plan to inverse this to false.

Since these polyfills require a manual step anyway it makes more sense to also enable them manually.

This creates a simpler default setup.