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

Drop some amount of corejs also the file in git tree #1772

Closed
wants to merge 4 commits into from

Conversation

mstoykov
Copy link
Contributor

Reasons for doing it this way:

  1. this lets us easily see what is actually included in the fina core-js
    build by looking at k6-shim.js. The format there is probably going to
    change as it is copied from the core-js repo's shim.js, but the idea
    will stay
  2. There is no need to have the shim.min.js in the git tree as it is
    already in lib/rice-box.go. Maybe after the golang embed proposal is
    available we can switch around, but this will likely take more then a
    year before we don't need to support a version of golang without it
  3. go generate is awesome, but in this case it has way too many things
    that need to happen which makes it IMO a bad fit. This plus the fact
    that this will not be changed regularly means it is probably better
    this way.

Reasons for doing it this way:
1. this lets us easily see what is actually included in the fina core-js
   build by looking at k6-shim.js. The format there is probably going to
   change as it is copied from the core-js repo's shim.js, but the idea
   will stay
2. There is no need to have the shim.min.js in the git tree as it is
   already in lib/rice-box.go. Maybe after the golang embed proposal is
   available we can switch around, but this will likely take more then a
   year before we don't need to support a version of golang without it
3. go generate is awesome, but in this case it has way too many things
   that need to happen which makes it IMO a bad fit. This plus the fact
   that this will not be changed regularly means it is probably better
   this way.
@mstoykov mstoykov added this to the v0.30.0 milestone Dec 15, 2020
@mstoykov mstoykov requested review from imiric, simskij and na-- December 15, 2020 15:50
@mstoykov
Copy link
Contributor Author

mstoykov commented Dec 15, 2020

Some performance running

import http from "k6/http";
import { sleep } from "k6";

export let options = {
    discardResponseBodies: true,
}
export default function() {
    http.get("https://httpbin.test.loadimpact.com/get");
    sleep(Math.random() * 2 + 3);
}

with -vus 500 --duration 60s main.js -v --no-thresholds --no-summary

version iterations mem usage CPU usage time to initialize VUs run time
15e15e5 7464 1424300 45% ~5.8s 1:10.90
0e6c0ab 7472 599880 24% ~3.2s 1:07.19
0e6c0ab + base 7473 279292 18% ~0.9s 1:05.81

The first is ( the current ) master, 0e6c0ab is this PR and +base is with compatility-mode=base and the same script rewritten to be es5.

@mstoykov
Copy link
Contributor Author

mstoykov commented Dec 15, 2020

Comment on the still available core-js modules:

  • es7.array.flat-map - this seems fine and probably something that can be added to goja by us

  • es7.array.flatten - same as above + it is now called flat and flatten doesn't exist see https://github.com/tc39/proposal-flatMap

  • es7.string.trim-left, trim-right are synonims (from AnnexB(b for browser)) to trimStart,trimEnd - again can be added to goja (even easier) and will probably be welcomed as they are used by babel7 for some reason 🤦

  • es7.string.match-all - can be added and probably won't be all that hard, but we will need some benchmark tests ;)

  • es7.object.get-own-property-descriptors - the variant without s is in goja, so adding this shouldn't be too hard.

  • es7.object.values, es7.object.entries - no idea but seems easy to be added

  • es7.object.define-getter, es7.object.define-setter, es7.object.lookup-getter,es7.object.lookup-setter - apparently deprecated, so maybe not even worth implementing 🤷

  • es7.reflect.define-metadata and friends are seem to be https://github.com/rbuckton/reflect-metadata which isn't even a proposal AFAIK ... https://medium.com/jspoint/introduction-to-reflect-metadata-package-and-its-ecmascript-proposal-8798405d7d88 So maybe dropping them is a good idea as well

compatibilityTestSrc := `
module.exports.default = function() {};
if ([[1,2],[3,4]].flatten()[4] == 4) {
throw Error("Array.flatten doesn't work")
Copy link
Contributor

@imiric imiric Dec 15, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would never fail, no? It would always be undefined, even if flatten() works, unless you meant [3] === 4. Ah, nevermind, the index doesn't actually matter. :)

But this would be better checked with if (typeof Array.prototype.flatten !== 'function') ....

Also maybe we should use a different object to test this, since flatten was renamed to flat in corejs v3, and it would avoid us having to update this when we update to v3.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But this would be better checked with if (typeof Array.prototype.flatten !== 'function') ....

We should have both of these. First check if it's actually a function, and fast fail if it's no, then whether the behavior is at least somewhat along the lines of what one could expect.

Also maybe we should use a different object to test this, since flatten was renamed to flat in corejs v3, and it would avoid us having to update this when we update to v3.

Array.prototype.flat is the actual name according to the specification. We should probably use that name as well.

Copy link
Contributor

@imiric imiric left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just some minor suggestions.

I like that we can easily see and change what's included in corejs 👍

The idea is that we would run build.sh manually whenever we want to upgrade, right?

js/lib/build.sh Outdated Show resolved Hide resolved
@@ -0,0 +1,5 @@
#!/bin/sh

npm i .
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is failing for me when I run build.sh. grunt fails to install because of:

npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving: [email protected]
npm ERR! Found: [email protected]
npm ERR! node_modules/grunt
npm ERR!   dev grunt@"1.0.x" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer grunt@"~0.4" from [email protected]
npm ERR! node_modules/grunt-livescript
npm ERR!   dev grunt-livescript@"0.6.x" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

npm i --force works, but maybe there's a better workaround.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm ... that seems to be because I don't specify a version for node and it works with mine (14.x something) while it doesn't work with 15.4.0

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

14.x is still the LTS, so as long as it works with that, I wouldn't bother. Usually, current, contains weird kinks until it reaches lts.

@imiric
Copy link
Contributor

imiric commented Dec 15, 2020

Also, that's an impressive performance gain! 👏 🎉

How did you know what to remove and what to keep? Can we assure that we're not removing something a script was relying on?

@mstoykov
Copy link
Contributor Author

@imiric mostly the discussion here dop251/goja#180 and talking with @simskij ... a long time ago. Plus obviously going through the things in the list from core-js v2.5.1 and looking at them, the test262 also helps ;)

Some of the drops might be used but also aren't standard at all ... just core-js used to (and probably still does) stuff that are still in the proposal process 🤦 - see the comments in k6-shim.js for it

#!/bin/sh

npm i --force .
modules="$(cat shim.js | grep ^require | sed "s|require('\./modules/||g" | sed "s/');//g" | tr "\n" ",")"
Copy link
Contributor

@imiric imiric Dec 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm not mistaken, you could simplify this to:

Suggested change
modules="$(cat shim.js | grep ^require | sed "s|require('\./modules/||g" | sed "s/');//g" | tr "\n" ",")"
modules="$(sed -n "s:^require('\./modules/\(.*\)');:\1:p" shim.js | paste -sd',')"

Also see useless use of cat ;)

Errm I messed up the quoting there so you'll need to escape it properly, but the command should work. Nevermind, it works fine with /bin/sh, just tested it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not going to this for now, as if we remove more from the shim.js or change its format, I will need to redo it.
For example, if we are finally left with 5-10 items I am probably just going to hard them inside the script instead of having a file with an explanation on what is what and why ;)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, though I don't see a reason why not to simplify this anyway.

Copy link
Contributor

@simskij simskij left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once @imiric's comments have been resolved. :)

@simskij
Copy link
Contributor

simskij commented Jan 5, 2021

es7.array.flatten - same as above + it is now called flat and flatten doesn't exist see https://github.com/tc39/proposal-flatMap

Yeah, we should drop this, once it's in goja. Couldn't find any mention of it in dop251/goja#180 or by lazily searching the codebase from the GH UI.

Yeah, if we ever get into any issues because of this, we can add it back or publish an article on how to polyfill it. My bet is that it won't ever happen.

es7.object.define-getter, es7.object.define-setter, es7.object.lookup-getter,es7.object.lookup-setter - apparently deprecated, so maybe not even worth implementing 🤷

Agreed. To sum it up, with some quite minor additions to goja, we should be able to drop the core-js shim layer altogether. 🎉

@mstoykov
Copy link
Contributor Author

As @simskij eluded we have agreed to drop the last two points of #1772 (comment) :

  • the metadata one, because it is not in the spec, or even in the process of getting in. Our implementation is 4 years old so it likely has changed, but also is very unlikely to be used by anyone inside k6
  • the define/lookup-getter/setter because they have been deprecated for around a decade from what I could find and again are unlikely to be used.
    Both of those can be polyfilled by people who need them in the cases where they do, so even if some users have used them for some reason, there is an easy fix for them.

Everything else has now been implemented in goja and as such we are dropping the whole corejs in #1824, which should land in v0.31.0.

And as such, I am closing this PR as it superseded.

@mstoykov mstoykov closed this Jan 28, 2021
@mstoykov mstoykov deleted the onlySomeCoreJSVer3 branch February 3, 2021 12:42
@mstoykov mstoykov restored the onlySomeCoreJSVer3 branch February 3, 2021 12:42
@mstoykov mstoykov deleted the onlySomeCoreJSVer3 branch February 3, 2021 12:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants