Passing options to individual components
smhg opened this issue · comments
I'm in a (sad) situation where one build pipeline has to support ES3 syntax (IE8).
With tinyify, I can't add the es3ify transform, because (the second) uglify run undoes its work without the ie8: true flag in its options. Moreover, ie8: true also does what es3ify does, so you'd actually just need that flag (in case someone ever wonders: the ie8 flag is necessary since uglify 2.7).
I guess in these more specific use-cases you could use the different transforms and plugins individually, but that creates some very long npm run scripts.
Would it be insane to add a third option, like env for envify, (e.g.) uglify with options merged into the result of makeUglifyOptions? Currently I can't imagine you want to pass something to the first uglify run, so I wouldn't worry about separating those.
The only other way out, I think, is to wrap es3ify as a plugin which runs after tinyify. I'm happy to take that road if you think the above is nonsense.
I actually tried that last path: create a plugin with es3ify that runs after tinyify. But it's not that straightforward because uglify without ie8: true does more IE8-incompatible things than what es3ify un-does.
Hmm, I'd prefer to have as few options as possible, especially for IE8 since it has been unsupported for so long. I think running es3ify after uglify would also...UN-uglify the code again which is unfortunate.
One idea, maybe you could write a small plugin that runs minify-stream again but with the ie8 option enabled? That would be a bunch slower because you'd run uglify twice on the final bundle, but it might work. Since its only for production builds the speed is hopefully not super important anyway.
If that doesn't work either I'd be open to adding an --ie8 or --es3 option.
Although indeed a much better approach, it doesn't seem to work.
Running uglify again with ie8: true doesn't make the IE8 error(s) go away.
The (first?) error the bundle produces is on e.attachEvent("onload",a), where e is undefined. To be clear: this doesn't throw without tinyify.
I'm perfectly fine with not running tinyify on this build.
It's an obvious request to expect about other options too though, no? Maybe it is, in a way, better to allow no options? Because you quickly go down the rabbit hole.
I'm going to close this as I agree it isn't the way to go. Thanks for your feedback!