use nolyfill to remove some polyfills

[techknowlogick]

We don't need to have polyfills down to Node v4. Some of our deps have polyfills, and don't utilize the built-in implementation if available. While this does decrease our package graph, I haven't been able to notice any decrease/increase in page load times, although that could likely be just because it's already pretty fast.

Nolyfill is https://github.com/SukkaW/nolyfill

updates to files generated with:

npx nolyfill install
npm update

Before this is/isn't merged, I'd be appreciative/thankful for other's insights.

Edit: This isn't due to a specific individual. I am generally supportive of them and their dedication to backward compatibility. This PR is due to not needing those imports for our minimum requirements. Please don't take this PR as commentary on anyone's character.

[silverwind]

Could it be ran at the end of make update-js, before the touch? We definitely want this to update whenever dependencies update.

[silverwind]

Most if not all of these polyfills come from ljharb's eslint plugins, so I imagine the impact on actual frontend bundle size will be neglible.

[silverwind]

See below

[silverwind]

Suggested change

	npm install --package-lock
	npx nolyfill install
	npm update
	npx nolyfill install
	npm install --package-lock

• We need to run it before npm install so that the changes it does take effect
• We never want to run npm update, we have npx updates to do the same job but better

[techknowlogick]

npm update is required because of an upstream bug where npm install doesn't respect the new field in package.json (the cli output shows the link to the bug)

[silverwind]

It links to npm/cli#5850 which says the bug manifests only for non-first installs and first install is when package-lock.json is absent which is the case here as we delete it before. So I don't think my suggestion is affected by that bug.

npm update at this point is pointless, except that is has the danger of upgrading "locked" dependencies.

[techknowlogick]

@silverwind awesome. thanks for looking into that :) I will update with your suggestion above.

[silverwind]

To slightly correct myself: "First install" scenario is when both package-lock.json and node_modules are absent which we guarantee above. Reason we do it that way is also to avoid npm/cli#4828. It seems npm has a number of unresolved bugs when not "first install" 😆.

[silverwind]

Actually I will give my suggestion a try because I'm not sure it's ideal to run npx nolyfill with no node_modules present, likely it will work but npx would install it to some temporary location and then install it once more from cache into node_modules. Probably unavoidable.