[postcss-preset-env] ability to inject js polyfill #208

Activity

1. fchastanet

   added

   feature requestNew feature or requestNew feature or request

   on Jan 27, 2022
2. romainmenke commented on Jan 27, 2022

   

   romainmenke

   on Jan 27, 2022

   Last edited by romainmenke

   Member

   More actions

   Hi @fchastanet

   There was a request for this here : #110 (comment)

   My main concern with providing something for this is that there are so many javascript tools. We can't support each but if we support one we will end up supporting all of them eventually.

   ---

   Would it help if we have a plugin option that takes a callback?

   const postcss = require('postcss');
   const postcssPresetEnv = require('postcss-preset-env');
   
   const neededJSPolyfills = [];
   
   postcss([
     postcssPresetEnv({
       didTransformCSS: (plugin) => {
         console.log(`plugin ${plugin} did run and transformed CSS`);
         if (plugin === 'blank-pseudo-class') {
           neededJSPolyfills.push('css-blank-pseudo/browser');
         }
       }
     })
   ]).process(YOUR_CSS /*, processOptions */);

   This callback is not specific to your use case but does expose the information you would need to dynamically inject the JS polyfills.

   At this time even the example above is not possible to provide quickly.
   Not all plugins are written and maintained by us and each would need to implement this.
3. fchastanet commented on Jan 27, 2022

   

   fchastanet

   on Jan 27, 2022

   Author

   More actions

   Hello @romainmenke
   Here the aim would be to warn the user that he has to install a JS polyfill.
   Does this callback would be called only if the feature needs a node module or for each feature no matter a js file is needed (I don't know if cssdb provide the list of needed javascript so you could know that information) ?
   But on the principle, the callback seems OK as I could just check that the node module is installed .
4. romainmenke commented on Jan 27, 2022

   

   romainmenke

   on Jan 27, 2022

   Member

   More actions

   In the upcoming 7.3 version there will be 2 new options that will also help with this.

   enableClientSidePolyfills will allow users to enable/disable these plugins with a single flag. This is true by default but will be changed to false in a future major version.

   debug will make the plugin log a lot of information about which plugins are enabled and why. This will also warn if plugins are enabled that require JS. But it doesn't know if you have CSS that would be transformed by these plugins.

   ---

   The extra feature of such a callback would be that it would only trigger when the plugin actually does something.

   Making it generic is more interesting as anyone could then build things on top of it for their need.

   If a plugin for example changes or is dropped (dead spec) then users might use it to find source code that depends on it.
5. fchastanet commented on Jan 27, 2022

   

   fchastanet

   on Jan 27, 2022

   Author

   More actions

   Maybe propose an interface that the plugin has to implement in order to be automatically installed by your tool.
   so your tool just calls the install method of these plugins if it exists and you have no more the need to support all of them. It's them that have to support you.
6. romainmenke commented on Jan 28, 2022

   

   romainmenke

   on Jan 28, 2022

   Member

   More actions

   Maybe propose an interface that the plugin has to implement in order to be automatically installed by your tool.
   so your tool just calls the install method of these plugins if it exists and you have no more the need to support all of them. It's them that have to support you.

   Definitely an option, but it might be confusing to users if some plugins support this and other don't. They would expect it to just always work :)

   I suggest we convert this issue to an open discussion and invite others to give feedback on the API proposal or give more insights in their needs.

   👍React with 👍1Reacted by François Chastanet
7. csstools

   locked and limited conversation to collaborators on Feb 5, 2022
8. romainmenke

   converted this issue into a discussion #228 on Feb 5, 2022