Giters

zloirock / core-js

Standard Library

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

core-js could use strict-mode for many files.

erights opened this issue · comments

commented

At endojs/endo#1655 (comment) @zloirock writes

core-js use strict mode, but, for modules size economy, not in all cases - for example, in cases where this depends on it. I didn't think that .arguments and .caller are interesting to anyone. I can consider adding the strict mode in all affected cases. You could open an issue in the core-js repo.

Thanks! This is that issue.

At endojs/endo#1655 (comment) I show the error message from SES initialization

Removing intrinsics.Iterator.from.arguments
  ✘ [fail]: shimmed iterator helpers Error thrown in test
failed to delete intrinsics.Iterator.from.arguments (TypeError#1)

This indicates that the Iterator.from function added by core-js is a sloppy function. I suspect but have not verified that Iterator.from is simply the first encountered of many similar cases.

commented

@erights beats me to it

Being implemented as CommonJS, core-js modules by default run in non-strict mode (aka sloppy mode). While some part of the core-js implementation do not rely on the non-strict semantics (e.g. this defaulting to global), most features do not and are actually strict mode compatible. Features implemented in non-strict mode end up having some observable differences when polyfilled: the .arguments and .caller properties exist on the functions, and unfortunately they're non-configurable.

This came up when using the new iterator helpers polyfill from core-js in an environment that is very strict about what intrinsics it finds, but I suspect a lot more part of core-js could run in strict mode without issues. See endojs/endo#1655 (comment)

Also this is likely a stepping stone towards ESM migration as all ES module code run as strict.

commented

most features do not and are actually strict mode compatible

I'm not sure that it makes them not compatible with strict mode - they are just defined in sloppy mode, but compatible -)

most features

Nope, just a little part of exported - mainly, it's static methods that don't rely on this, CRUD properties, or other popular differences between strict and sloppy modes semantic. For example, it's Math methods. And methods non-observable outside.

Also this is likely a stepping stone towards ESM migration as all ES module code run as strict.

I'm not sure that it's significantly related.

I'll explore what I can do.