especially
especially copied to clipboard
Create especially-lite
I'd like to create another version of especially that is usable by polyfills, not just reference implementations. It should not depend on Node 0.11 --harmony mode, but instead be usable by all ES5 browsers. (And, a subset of it might be usable by ES3 browsers.)
Its readme would document where it departs from especially. For example, it will likely be missing most constructor-related abstract operations, or perhaps would only polyfill the top-level one in an inaccurate fashion (by using new). And it would either be missing the internal slot stuff, or just add them as underscored-properties.
Then, especially-lite could be used by Traceur and es6-shim. /cc @arv @ljharb
+1, this would be great. I'm building the es7-shim now, and it will use browserify to concatenate dependencies, so that there won't be any shim code in the module directly. If I can ever move the es5-shim and es6-shim over to a similar build process, then I'd use them there too.
I want to make sure to add: it would need to run in all browsers and all nodes to be useful, not just node 0.11 --harmony
What do you think about creating about a separate module for each abstract operation?
+1 for that, a module should do as close to one thing as possible :-)
I'm not a big fan of that kind of "manual tree shaking." I think tree-shaking should be done by the minifier, not by the package ecosystem. Evolving the set of abstract operations and other helpers in tandem allows good reuse.
That said, abstract-operations.is getting kind of big, and may need to be broken up into a few files that it requires and re-exports.
Isn't it possible/viable to compile especially with Babel using the runtime transformer and ship a browserified bundle?
it'd be nice to do:
import { Invoke } from 'especially/abstract/invoke'
Agree. But I guess you mean either:
import { Invoke } from 'especially/abstract-operations';
Or:
import Invoke from 'especially/abstract-operations/invoke';
I would favor the first approach, in order to avoid creating a new file for each operation. You should be able to remove dead code using Webpack 2 or Rollup then.
@UltCombo ah whoops. good catch. yes. no curly braces.
and yes. good point about webpack 2. the tree shaking is lovely. in this case, i'd favor the first approach as well :+1: