Optimise builds depending on consumer capability
Buzut opened this issue · 5 comments
I see that in the Rollup config, everything is transpiled by default. That shouldn't be as it is clear that ES2015+ code is smaller and faster to execute.
As a matter of fact, all modern (not depreacated) Node.js servers can execute ES2015 code, as well as all browsers consuming ES modules (as stated by Google).
So this code:
passesAnyOf: (...validations) => value =>
validations.some(validation => validation.test(value)),would be better off left untouched, whereas it's currently transpiled to this:
passesAnyOf: function passesAnyOf() {
for (var _len = arguments.length, validations = Array(_len), _key = 0; _key < _len; _key++) {
validations[_key] = arguments[_key];
}
return function (value) {
return validations.some(function (validation) {
return validation.test(value);
});
};
},This should only require a few lines in the Rollup config. Not sure if I will get around to it though.
Why not just left code as-is for the es-modules?
It's the consummer responsibility to further compile it if needed.
The rationale is that if you ship compiled code, you give no choice to the developer using your lib whether he wants to ship modern, optimised code to the users.
On the other hand, with module being just raw (but standard) modern JS, anyone can do as they see fit. That's roughly Babel team's opinion too.
If it seems like a fair option to you, I'd be happy to PR the changes for that to happen.
PS: that would obviously not impact either main nor jsdelivr, so tools not module aware wouldn't notice the difference.
I actually like the approach the Vue.js repo uses. They have an esm.browser build, which uses ES modules and is browser ready. This is what I think we should do too. I don't see what other changes are necessary? I feel like all we need is an additional build.
Seems good to me! Waiting for the merge and will be using it promptly 👍