Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimise builds depending on consumer capability #165

Closed
Buzut opened this issue Sep 30, 2019 · 5 comments · Fixed by #177
Closed

Optimise builds depending on consumer capability #165

Buzut opened this issue Sep 30, 2019 · 5 comments · Fixed by #177

Comments

@Buzut
Copy link

Buzut commented Sep 30, 2019

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);
      });
    };
  },
@sbarfurth
Copy link
Collaborator

sbarfurth commented May 12, 2020

This should only require a few lines in the Rollup config. Not sure if I will get around to it though.

@Buzut
Copy link
Author

Buzut commented May 12, 2020

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.

@sbarfurth
Copy link
Collaborator

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.

@sbarfurth
Copy link
Collaborator

@Buzut see #177

@Buzut
Copy link
Author

Buzut commented Nov 17, 2020

Seems good to me! Waiting for the merge and will be using it promptly 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants