6 ms·
I see they’re solving the dependent plugins problem by making the plugin smart; I prefer the approach taken by Dist::Zilla[0], where resolving is done manually
by falsedan 9y ago
I see they’re solving the dependent plugins problem by making the plugin smart; I prefer the approach taken by Dist::Zilla[0], where resolving is done manually by the user, by specifying the order they run in, in the config file.
0: https://metacpan.org/pod/Dist::Zilla::Tutorial#HOW-BUILDS-GET-BUILT https://metacpan.org/pod/Dist::Zilla::Tutorial#HOW-BUILDS-GE...
- shados 9y agoHow does that work for internal plugins? Webpack itself is essentially nothing BUT a stack of internal plugins (the webpack core does almost nothing, even internally). So how do you order plugins relative to other plugins you don't have control over? (This is an honest question, as I'm trying to solve a similar issue in one of my projects)
- falsedan 9y ago> So how do you order plugins relative to other plugins you don't have control over? Let the user decide, like this? [external plugin 1] some options = do stuff [internal plugin A] ; etc. [external plugin 2] [external plugin 3] [internal plugin B] where all of these plugins are the same type (e.g. pre-build, post-compile). If that's too verbose, then plugin bundles & the Filter bundle are the way to go: [external plugin 1] some options = do stuff [internal plugin A] ; etc. [@Filter/@Basic] -without = external plugin 1 [internal plugin B] If you have a strong need for your plugin to run after one but before another, and they're all in the same step, then maybe they should be separated into two steps.