esm: provide named exports for all builtin libraries #18131

devsnek · 2018-01-13T10:29:10Z

provide named exports for all builtin libraries so that the libraries may be
imported in a nicer way for esm users: import { readFile } from 'fs'
instead of importing the entire namespace, import fs from 'fs', and
calling fs.readFile

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
tests and/or benchmarks are included
documentation is changed or added
commit message follows commit guidelines

bnoordhuis

Only very lightly reviewed. No opinion on whether this is a good or bad change.

bnoordhuis · 2018-01-13T11:31:27Z

doc/api/esm.md

+foo.one === 1 // true
+```
+
+Builtin modules such as will provide the above with the addition of their


Missing word after 'such as.'

bnoordhuis · 2018-01-13T11:36:10Z

tools/js2c.py

-    var = name.replace('-', '_').replace('/', '_')
+    if name.endswith('.js'):
+      name = name.split('.', 1)[0]
+    var = name.replace('-', '_').replace('/', '_').replace('.', '_')


var = re.sub(r'[\-./]', '_', name)

bnoordhuis · 2018-01-13T11:37:52Z

tools/esmgen.js

@@ -0,0 +1,46 @@
+const builtins = require('repl')._builtinLibs;


'use strict';

bnoordhuis · 2018-01-13T11:39:11Z

lib/internal/loader/ModuleRequest.js

-  if (NativeModule.nonInternalExists(specifier)) {
+  if ((/^node:/.test(parentURL) &&
+       NativeModule.nonInternalExists(specifier.replace(/\.js$/, '')))
+      || NativeModule.nonInternalExists(specifier)) {


Operator should go on the previous line.

guybedford · 2018-01-13T12:08:12Z

👍 strongly for merging this.

My only comment would be if there might not be a maintenance burden being created by this approach that might be mitigated with enumeration of the exports at load time, provided we can ensure we don't expose the wrong things (perhaps filtering _... properties etc). Would be interested to hear thoughts on this approach.

guybedford

I've included my comments... hope you don't mind all the questions :)

guybedford · 2018-01-13T12:10:44Z

lib/internal/loader/Loader.js

@@ -91,7 +91,7 @@ class Loader {
      throw new errors.TypeError('ERR_INVALID_ARG_TYPE', 'url', 'string');
    }

-    if (format === 'builtin') {
+    if (format === 'builtin/esm' || format === 'builtin/cjs') {


Why do we need two forms of builtin? Can the builtin/esm not entirely replace the builtin/cjs? What is the use case for retaining builtin/cjs?

guybedford · 2018-01-13T12:11:59Z

lib/internal/loader/ModuleRequest.js

-      format: 'builtin'
-    };
+  if (/^node:/.test(parentURL) && parentURL.slice(5) === specifier) {
+    return { url: `${specifier}.js`, format: 'builtin/cjs' };


When does this case ever happen?

when the esm wrapper imports the actual cjs it looks like node:assert requesting assert, and thats the only time the builtin cjs should get used

guybedford · 2018-01-13T12:13:22Z

tools/esmgen.js

+  test.push(`check(${name}, ${key});`);
+}
+
+console.log(test.join('\n'));


Is the assumption that this file is run periodically to update the lib folder? Is there a way to make this more automated? Why would you think this level of automation is preferable to runtime enumeration?

hopefully it never needs to be used again, but i still included it since it might be useful at some point, maybe during a refactor or something in the far future

devsnek · 2018-01-13T16:24:05Z

@guybedford i chose this over runtime enumeration because of the results in my last pr where i attempted forward evaluation but i guess if we can guarantee our libs won't have errors on evaluation it should be fine? i don't think our public api changes that much for it to be a real burden. this also lays groundwork for writing core parts of node in esm, although i don't know if that matters much to people. it should be noted that if we switch to runtime enumerating with out of order evaluation then the current issues i'm having with tests will also go away, and it will get rid of people who make loaders worrying about resolving both kinds builtins, which is definitely a confusing process.

guybedford · 2018-01-13T16:28:49Z

@devsnek thanks for clarifying. Personally I think the runtime creation would be better as it would avoid the need for the new builtin interpretation mode, remove the maintenance burden of maintaining the wrappers (generated or not), and it would effectively be exactly the same algorithm to build up the exports, saving an extra file load anyway to do that.

devsnek · 2018-01-13T16:29:51Z

@guybedford i just know there was significant opposition to out-of-order evaluation in my previous pr, but maybe @bmeck its fine in this case?

guybedford · 2018-01-13T16:34:17Z

Personally I don't seen an issue with considering core modules "preevaluated" (from the esm loader perspective). It's user dependencies with circular references and errors that we have to worry about for that issue.

bmeck · 2018-01-13T16:36:14Z

I don't like that the exports can go out of sync but am not blocking that at this point. I'd love it if the backing object could stay in sync for a variety of reasons, but all approaches I've tested are problematic for performance.

bmeck · 2018-01-13T16:39:23Z

@devsnek could you make the ESM facades eagerly populate even when required so that they stay the true primordial form of the exports?

devsnek · 2018-01-13T16:41:14Z

@bmeck i'm not sure what you mean by "true primordial form" but my method would basically be:

loaders.set('builtin', async (url) => {
  const module = InternalModule.require(url.slice(5));
  const properties = Object.getOwnPropertyDescriptors(module);
  const keys = ['default'];
  for (const [name, prop] of Object.entries(properties)) {
    if (!prop.enumerable || !prop.value)
      continue;
    if (/(^_)|(_$)/.test(name))
      continue;
    keys.push(name);
  }
  return createDynamicModule(keys, url, (reflect) => {
    reflect.exports.default.set(module);
    for (const key of keys)
      reflect.exports[key].set(module[key]);
  });
});

bmeck · 2018-01-13T16:43:20Z

@devsnek I just want to be sure that if you mutate fs it does not mutate the named export value depending on timing.

const fs = require('fs');
fs.readFile = () => {}

import {readFile} from 'fs';
// should never be that noop function (even if this file is loaded after the one above)

devsnek · 2018-01-13T16:45:11Z

@bmeck i don't know of any way to guarantee at all, even requiring every builtin before user code runs and keeping a cache would still allow user mutation of the exports object.

guybedford · 2018-01-13T16:46:42Z

@devsnek the same sort of technique we use to eagerly inject CJS modules into the loader registry for this should work here for the core modules I think?

guybedford · 2018-01-13T16:47:10Z

(I know it's not pretty, but it provides the invariants)

jasnell · 2018-01-13T17:16:54Z

lib/assert.mjs

@@ -0,0 +1,19 @@
+/* eslint-disable no-restricted-properties */


Just a thought... could we not devise a mechanism for generating these automatically during the build so we do not need to keep them manually in sync? The surface area of core modules is fixed at time of build.

@jasnell we could somehow with static parsing maybe, but various things like getter/setters would need to be excluded.

jasnell · 2018-01-13T17:18:12Z

lib/assert.mjs

+export const notStrictEqual = assert.notStrictEqual;
+export const throws = assert.throws;
+export const doesNotThrow = assert.doesNotThrow;
+export const ifError = assert.ifError;


This appears to be missing the new strict export.

it might not have been in my branch when i generated these, but since i'm changing this to generate the exports at runtime it shouldn't be an issue. (stay tuned!! 😄)

jasnell · 2018-01-13T17:21:33Z

lib/crypto.mjs

+export const pbkdf2Sync = crypto.pbkdf2Sync;
+export const privateDecrypt = crypto.privateDecrypt;
+export const privateEncrypt = crypto.privateEncrypt;
+export const prng = crypto.prng;


We should decide if we really want to export pure aliases or take the opportunity to begin limiting access to those

can you expand on the reason to limit access to things?

jasnell · 2018-01-13T17:22:24Z

lib/domain.mjs

@@ -0,0 +1,7 @@
+import domain from 'domain';


Should we export deprecated modules at all?

+0 to removing them, not blocking on it

guybedford · 2018-01-13T19:25:48Z

New approach looks good.

bmeck

lgtm

ljharb · 2018-01-13T20:24:16Z

lib/internal/bootstrap_node.js

+      const descriptors =
+        Object.getOwnPropertyDescriptors(nativeModule.exports);
+      for (const [name, d] of Object.entries(descriptors)) {
+        if (d.setter !== undefined || d.getter !== undefined || !d.enumerable)


what is "setter" and "getter"? Property descriptors have set and get.

jdalton · 2018-04-23T07:02:23Z

lib/internal/bootstrap/loaders.js

+                  Reflect.defineProperty(target, prop, descriptor)) {
+                update(prop, valueDescriptor.value);
+                return true;
+              }


👆 In the if (valueDescriptor && condition you can make it if (valueDescriptor) { then inside the block capture the result of Reflect.defineProperty(target, prop, descriptor), call update and return the captured result.

jdalton · 2018-04-23T07:04:24Z

lib/internal/bootstrap/loaders.js

+            if (this.namespace.includes(prop))
+              return false;
+            return delete target[prop];
+          },


👆 By returning false you're making the CJS export objects non-delete able. Instead you could allow the operation to happen, capturing the result of Reflect.deleteProperty(target, prop), calling update, then returning the captured result. If a property is deleted its updated value is undefined or whatever is exposed on its prototype.

calling update

calling it with what exactly? the property is gone if we let it get deleted

calling it with what exactly? the property is gone if we let it get deleted

Whatever the value of target[prop] that's remaining.

jdalton · 2018-04-23T08:21:25Z

lib/internal/bootstrap/loaders.js

+            }
+            return value;
+          },
+        });


I take a slightly different approach to wrapping. Instead of creating a new wrap function, I proxy the original.

Is there a reason why you would prefer that?

@TimothyGu Yes. I first avoid wrapping for the 99% case (plain or bound functions) and then only wrap with a proxy for the native case. For the 1% case (native method) wrapping with a proxy lets all other traps passthru to the original function while I just hook the apply trap.

Beyond the fact that less wrapping is good in general this is important to the esm loader because folks can opt for CJS named export support beyond buitlins. Avoiding the function/proxy wrap means more methods are === to other references a user might store.

I'll have to re-audit our exports to make sure we only need to bind for native methods, but that does seem like a better case

@jdalton your proxy unfortunately breaks in certain cases which i think could be a v8 bug so i'll keep using my wrap function for now

@nodejs/v8

> Reflect.apply(EventEmitter.call, EventEmitter, []) TypeError: Reflect.apply is not a function

@jdalton i wasn't running any esm, it broke regular usage of event emitter. it seems like v8 doesn't enjoy Function.prototype.call and Reflect.apply together, this isn't just an issue with EventEmitter.

var EventEmitter = require('events'); // probably some ghetto es3 function extending EventEmitter EventEmitter.call(...);

i can special case the thisArg variable like value === Function.prototype.call but that feels nasty and the wrap works

Dev error? Proxies should work.
Can you show how you attempted proxies. Might be able to spot the issue.

In my implementation

EventEmitter.call({})

works. The .call is proxy wrapped.

I have smth like this for the handler (poke around the implementation here)

wrapper = new Proxy(value, { apply(funcTarget, thisArg, args) { if (thisArg === proxy || thisArg === entry.esmNamespace) { thisArg = target } return Reflect.apply(value, thisArg, args) } })

When EventEmitter.call({}) is called the thisArg === proxy condition is met because var EventEmitter is the events module module.exports proxy. The thisArg is set to the original target (the unwrapped module.exports of events). This results in a successful invocation.

@devsnek Can you find an isolated reproduction of the bug? The following seems to be working just fine here:

$ node > const { EventEmitter } = events undefined > Reflect.apply(EventEmitter.call, EventEmitter, []) TypeError: Cannot set property 'domain' of undefined at EventEmitter.init (domain.js:401:15) at EventEmitter (events.js:27:21)

@jdalton i copied yours in, except for using regular proxies instead of your OwnProxy, which i doubt makes any difference in this case

ok i just came back to this and it seems like the proxy works now so i'm going to just assume i need more sleep... i'll push in a few minutes after some more testing

TimothyGu · 2018-04-23T15:55:57Z

lib/util.js

@@ -433,7 +436,7 @@ function formatValue(ctx, value, recurseTimes, ln) {
    return ctx.stylize('null', 'null');
  }

-  if (ctx.showProxy) {
+  if (ctx.showProxy && !nativeModuleProxies.has(value)) {


I don't think we should make a distinction between "our proxies" versus "their proxies".

We should either disable proxy showing by default, or just show the proxy.

@TimothyGu It's cosmetic and can totally be tackled in a follow-up PR. The idea from earlier in the thread was that folks thought it would be less-good displaying the Proxy prefix when inspecting builtin module exports in the repl.

I'd like to argue in the other way: because it is cosmetic, this change can be done in a follow-up PR. Changes should be atomic and focused on one topic at a time.

I'd like to argue in the other way: because it is cosmetic, this change can be done in a follow-up PR.

We're on the same page. I was saying that the masking of builtin exports could be done in a follow-up PR instead of this one 😁

TimothyGu

Good progress, but a bit more work is still needed.

Also, how much does this slow down require()ing an internal module (and Node.js startup) from CJS with the --experimental-modules flag turned on? We could get this in with a performance hit, but we need to be able to quantify that and know what to fix in the future.

TimothyGu · 2018-04-24T00:37:27Z

lib/internal/bootstrap/loaders.js

+          },
+          defineProperty(target, prop, descriptor) {
+            if (Reflect.defineProperty(target, prop, descriptor)) {
+              update(prop, Reflect.get(target, prop, target));


Last , target is unneeded.

TimothyGu · 2018-04-24T00:38:52Z

lib/internal/modules/esm/translators.js

-    const exports = NativeModule.require(url.slice(5));
-    reflect.exports.default.set(exports);
-  });
+  const id = url.substr(5);


What exactly does this do? A comment would help with what exactly this truncates. Also we generally use .slice() (substr is part of Annex B).

TimothyGu · 2018-04-24T00:40:44Z

test/fixtures/es-module-loaders/js-loader.mjs

@@ -1,10 +1,11 @@
-import _url from 'url';
+import { URL } from 'url';


No need to import URL at all in Node.js v10.x :)

you never know where this might be backported to

TimothyGu · 2018-04-24T00:44:37Z

lib/internal/bootstrap/loaders.js

+          this.namespace = Object.entries(
+            Object.getOwnPropertyDescriptors(this.exports))
+            .filter(([name, d]) => d.enumerable)
+            .map(([name]) => name);


Core code rarely use the functional array methods. Let's make this imperative instead.

this.namespace = []; for (const key of Object.getOwnPropertyNames(this.exports)) { const desc = Object.getOwnPropertyDescriptor(this.exports, key); if (!desc.enumerable) continue; namespace.push(key); }

mfw thats what i was using before 😢 will change back

TimothyGu · 2018-04-24T00:58:02Z

lib/internal/bootstrap/loaders.js

+        const proxy = new Proxy(this.exports, {
+          set(target, prop, value) {
+            if (Reflect.set(target, prop, value)) {
+              update(prop, value);


For consistency with defineProperty, use update(prop, Reflect.get(target, prop)). (This behavior is observable through getters/setters.)

TimothyGu · 2018-04-24T01:23:03Z

lib/internal/bootstrap/loaders.js

+        const methodWrapMap = new WeakMap();
+
+        const proxy = new Proxy(this.exports, {
+          set(target, prop, value) {


set hook has a fourth receiver argument that you are not handling.
You need to at least make sure to forward the receiver argument to Reflect.set.

TimothyGu · 2018-04-24T01:23:27Z

lib/internal/bootstrap/loaders.js

+            }
+            return false;
+          },
+          get(target, prop) {


You need to handle receiver here as well.

TimothyGu · 2018-04-24T01:43:28Z

lib/internal/bootstrap/loaders.js

+              wrap.prototype = value.prototype;
+              methodWrapMap.set(value, wrap);
+              return wrap;
+            }


You might need to add this handling for getOwnPropertyDescriptor as well.

TimothyGu · 2018-04-24T01:44:19Z

test/es-module/test-esm-live-binding.mjs

+fs.readFile = () => s;
+
+assert.strictEqual(fs.readFile(), s);
+assert.strictEqual(readFile(), s);


Still need to test:

delete

delete and set afterwards

set

defineProperty

All of the above, but with accessor properties

jdalton · 2018-04-24T02:26:38Z

lib/internal/bootstrap/loaders.js

+        for (const key of Object.getOwnPropertyNames(this.exports)) {
+          const desc = Object.getOwnPropertyDescriptor(this.exports, key);
+          if (desc.enumerable)
+            this.namespace.push(key);


Instead of getOwnPropertyNames+enumerable check you could use Object.keys

devsnek · 2018-04-24T02:38:55Z

@TimothyGu

average startup time with child process + loop + console.log(perf_hooks.performance.nodeTiming) + shameless rounding:

without proxy (1000 runs) 79.71845515598729
with proxy (1000 runs) 90.33686945802346

i didn't bother testing time of an individual require because it can only happen at max once. its also worth nothing this increased time should be more than handled by snapshots, whenever we finish those.

jdalton · 2018-04-24T02:44:11Z

lib/internal/bootstrap/loaders.js

+
+          if (typeof value.name === 'string' && /^bound /.test(value.name))
+            return value;
+


Besides non-functions and bound-functions you can also skip non-native functions.
I have an inference method here for reference. (a v8 helper for this would be rad++)

we can't skip native functions. for instance if you do module.exports = new Map() and we don't wrap the exports then Map.prototype.* will have improper receivers and throw

we can't skip native functions.

I know, I'm saying skip non-native.

so the only functions we bind then are unbound native functions? what about member functions written in js

so the only functions we bind then are unbound native functions? what about member functions written in js

We aren't binding functions. The wrapper juggles the thisArg around for the one, maybe two, cases that cause native methods grief but beyond that we forward the thisArg along. So it makes sense to only wrap the methods that need the thisArg juggling in the first place (native methods).

jdalton · 2018-04-24T03:26:56Z

lib/internal/bootstrap/loaders.js

+            apply(t, thisArg, args) {
+              if (thisArg === proxy)
+                thisArg = target;
+              return Reflect.apply(t, thisArg, args);


You might end up needing a thisArg === nsObj check.
A test for calling a native method on the namespace object would cover it.

devsnek · 2018-04-28T23:08:25Z

alright so this is the 400th comment in this thread and i'm starting to consistently get the github unicorn when loading this. at the moment it works and this pr seems to be ready. that being said, i need some approvals on this. i would love to land this by the end of next week.

jdalton · 2018-04-28T23:26:13Z

👍 As an initial landing of an experimental feature I think it's great. Every time I look at this implementation I find something in my own to improve! There are some things to dry-up and tweak here but they can be tackled in follow-up PRs.

provide named exports for all builtin libraries so that the libraries may be imported in a nicer way for esm users: `import { readFile } from 'fs'` instead of importing the entire namespace, `import fs from 'fs'`, and calling `fs.readFile`. the default export is left as the entire namespace (module.exports)

giltayar · 2018-04-29T05:31:53Z

And, given that it's not a semver change (I think...), I believe there should be no problem to land it?

…

On Sun, Apr 29, 2018 at 2:26 AM John-David Dalton ***@***.***> wrote: 👍 As an initial landing of an experimental feature I think it's great. Every time I look at this implementation I find something in my own to improve! There are some things to dry-up and tweak here but they can be tackled in follow-up PRs. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18131 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYnRN0X4rkV7THOoKvx1uxnqEepfnzRks5ttPq_gaJpZM4RdLYy> .

ljharb · 2018-04-29T05:54:52Z

lib/internal/bootstrap/loaders.js

+        this.exportKeys = Object.keys(this.exports);
+
+        const update = (property, value) => {
+          if (this.reflect !== undefined && this.exportKeys.includes(property))


is it ok that delete Array.prototype.includes can break this code?

If not, you could copy Array.prototype.includes to be an own property on this.exportKeys, perhaps?

(same question on has/get/set on collection instances)

@ljharb There's another issue (here) for isolating internals to avoid ad hoc primordial scaffolding in each module. Trying to isolate includes, Object.keys, Reflect or other is probably out of scope for this specific PR (esp. since it's experimental and the issue is larger than this PR).

Fair point, just wanted to call it out :-)

ljharb · 2018-04-29T05:57:49Z

lib/internal/modules/esm/translators.js

+  NativeModule.require(id);
+  const module = NativeModule.getCached(id);
+  return createDynamicModule(
+    [...module.exportKeys, 'default'], url, (reflect) => {


i'm not sure if the ordering matters here at all - is default always last?

https://tc39.github.io/ecma262/#sec-modulenamespacecreate step 7 suggests that all export keys, including "default" if present, should be alphabetically sorted. (i do see at least one test that validates the ordering, but i'm not sure if that test covers this code or not)

the order doesn't matter there actually as it just gets injected into a generated source text

guybedford · 2018-04-29T09:27:07Z

My greatest concern here is the potential 10% performance slowdown for NodeJS app startup having all core modules as proxies in CommonJS code, as Gus provided in some numbers at #18131 (comment).

It may turn out that creating setter-based core modules could be an alternative to the proxy approach that is also faster, so I do think this would still be worth seriously considering, or at least comparing for performance.

The benefit of a proxy over just a setter is supporting dynamic properties and object.defineProperty configuration cases. But dynamic properties are already not supported, so perhaps benefits may be worth the loss of configuration hooks.

devsnek · 2018-04-29T13:28:36Z

@guybedford as long as the experimental flag is around i'd rather take it as an opportunity to experiment with the behaviour rather than perf optimisation. come time to ship it we can always make it more performant if needed. i'm also exceedingly hopeful that we will finish up snapshots by that time and then we won't have to worry this at all

guybedford · 2018-04-29T13:40:48Z

There is an important distinction between experimentation that doesn't affect legacy at all, and experimentation that creates a performance regression for existing code. I really don't think a 10% reduction in NodeJS startup time for existing codebases is a trivial matter to push through. Yes lets move fast with the modules work, but let's not slow down existing NodeJS apps in the process. I'm also starting to get the unicorn for this page consistently - it is probably worth closing this PR and opening a new one at this point I think to reset discussion for review.

…

On Sun, Apr 29, 2018 at 3:28 PM Gus Caplan ***@***.***> wrote: @guybedford <https://github.com/guybedford> as long as the experimental flag is around i'd rather take it as an opportunity to experiment with the behaviour rather than perf optimisation. come time to ship it we can always make it more performant if needed. i'm also exceedingly hopeful that we will finish up snapshots by that time and then we won't have to worry this at all — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18131 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAkiykOyOSII3TlhpYZvz4DcudoJs4Sjks5ttcAKgaJpZM4RdLYy> .

devsnek · 2018-04-29T13:41:39Z

@guybedford this code doesn't run unless the flag is given, and yes i would agree a new pr is probably a good idea

Docs-only deprecate the getter/setter crypto.fips and replace with crypto.setFips() and crypto.getFips() This is specifically in preparation for ESM module support PR-URL: nodejs#18335 Refs: nodejs#18131 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Guy Bedford <guybedford@gmail.com> Reviewed-By: Jon Moss <me@jonathanmoss.me> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

Runtime deprecate the crypto.DEFAULT_ENCODING property. This is specifically in preparation for eventual ESM support Refs: nodejs#18131 PR-URL: nodejs#18333 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Minwoo Jung <minwoo@nodesource.com> Reviewed-By: Tobias Nießen <tniessen@tnie.de>

Docs-only deprecate the getter/setter crypto.fips and replace with crypto.setFips() and crypto.getFips() This is specifically in preparation for ESM module support PR-URL: nodejs#18335 Refs: nodejs#18131 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Guy Bedford <guybedford@gmail.com> Reviewed-By: Jon Moss <me@jonathanmoss.me> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>

nodejs-github-bot added the lib / src Issues and PRs related to general changes in the lib or src directory. label Jan 13, 2018

devsnek force-pushed the esm-builtin-module-namespaces branch from f4ea88b to 90c22d0 Compare January 13, 2018 10:33

bnoordhuis reviewed Jan 13, 2018

View reviewed changes

devsnek force-pushed the esm-builtin-module-namespaces branch from 90c22d0 to 9000c54 Compare January 13, 2018 11:42

guybedford reviewed Jan 13, 2018

View reviewed changes

jasnell reviewed Jan 13, 2018

View reviewed changes

devsnek force-pushed the esm-builtin-module-namespaces branch from 9000c54 to 43bfe9e Compare January 13, 2018 18:03

devsnek changed the title ~~esm: provide wrappers for all builtin libraries~~ esm: provide named exports for all builtin libraries Jan 13, 2018

devsnek force-pushed the esm-builtin-module-namespaces branch from 43bfe9e to e46ccb8 Compare January 13, 2018 18:05

guybedford approved these changes Jan 13, 2018

View reviewed changes

bmeck approved these changes Jan 13, 2018

View reviewed changes

ljharb suggested changes Jan 13, 2018

View reviewed changes

jasnell previously approved these changes Jan 13, 2018

View reviewed changes

devsnek force-pushed the esm-builtin-module-namespaces branch from e46ccb8 to c63e761 Compare January 13, 2018 20:43

devsnek force-pushed the esm-builtin-module-namespaces branch from f2627aa to e1770a2 Compare April 23, 2018 06:31

jdalton reviewed Apr 23, 2018

View reviewed changes

devsnek force-pushed the esm-builtin-module-namespaces branch from a3284c6 to 2991f5c Compare April 23, 2018 07:12

jdalton reviewed Apr 23, 2018

View reviewed changes

TimothyGu reviewed Apr 23, 2018

View reviewed changes

TimothyGu reviewed Apr 24, 2018

View reviewed changes

devsnek force-pushed the esm-builtin-module-namespaces branch 2 times, most recently from 716aec6 to c40ac4d Compare April 24, 2018 02:04

jdalton reviewed Apr 24, 2018

View reviewed changes

devsnek force-pushed the esm-builtin-module-namespaces branch 2 times, most recently from 0975efa to cb20994 Compare April 28, 2018 21:18

devsnek force-pushed the esm-builtin-module-namespaces branch from cb20994 to 3aabe35 Compare April 29, 2018 03:03

ljharb approved these changes Apr 29, 2018

View reviewed changes

devsnek closed this Apr 29, 2018

devsnek mentioned this pull request Apr 29, 2018

esm: provide named exports for builtin libs #20403

Closed

4 tasks

		@@ -0,0 +1,46 @@
		const builtins = require('repl')._builtinLibs;

		@@ -0,0 +1,19 @@
		/* eslint-disable no-restricted-properties */

		@@ -1,10 +1,11 @@
		import _url from 'url';
		import { URL } from 'url';


		if (typeof value.name === 'string' && /^bound /.test(value.name))
		return value;

esm: provide named exports for all builtin libraries #18131

esm: provide named exports for all builtin libraries #18131

Conversation

devsnek commented Jan 13, 2018 • edited Loading

Checklist

bnoordhuis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

guybedford commented Jan 13, 2018

guybedford left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

devsnek Jan 13, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

devsnek Jan 13, 2018 • edited Loading

Choose a reason for hiding this comment

devsnek commented Jan 13, 2018 • edited Loading

guybedford commented Jan 13, 2018

devsnek commented Jan 13, 2018

guybedford commented Jan 13, 2018 • edited Loading

bmeck commented Jan 13, 2018

bmeck commented Jan 13, 2018

devsnek commented Jan 13, 2018 • edited Loading

bmeck commented Jan 13, 2018

devsnek commented Jan 13, 2018

guybedford commented Jan 13, 2018

guybedford commented Jan 13, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

guybedford commented Jan 13, 2018

bmeck left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jdalton Apr 23, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

devsnek Apr 23, 2018 • edited Loading

Choose a reason for hiding this comment

jdalton Apr 23, 2018 • edited Loading

Choose a reason for hiding this comment

jdalton Apr 23, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jdalton Apr 23, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

devsnek Apr 23, 2018 • edited Loading

Choose a reason for hiding this comment

devsnek Apr 23, 2018 • edited Loading

Choose a reason for hiding this comment

jdalton Apr 23, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

devsnek Apr 24, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jdalton Apr 23, 2018 • edited Loading

Choose a reason for hiding this comment

TimothyGu Apr 23, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TimothyGu left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

devsnek commented Jan 13, 2018 •

edited

Loading

devsnek Jan 13, 2018 •

edited

Loading

devsnek Jan 13, 2018 •

edited

Loading

devsnek commented Jan 13, 2018 •

edited

Loading

guybedford commented Jan 13, 2018 •

edited

Loading

devsnek commented Jan 13, 2018 •

edited

Loading

jdalton Apr 23, 2018 •

edited

Loading

devsnek Apr 23, 2018 •

edited

Loading

jdalton Apr 23, 2018 •

edited

Loading

jdalton Apr 23, 2018 •

edited

Loading

jdalton Apr 23, 2018 •

edited

Loading

devsnek Apr 23, 2018 •

edited

Loading

devsnek Apr 23, 2018 •

edited

Loading

jdalton Apr 23, 2018 •

edited

Loading

devsnek Apr 24, 2018 •

edited

Loading

jdalton Apr 23, 2018 •

edited

Loading

TimothyGu Apr 23, 2018 •

edited

Loading

devsnek commented Apr 24, 2018 •

edited

Loading

jdalton Apr 24, 2018 •

edited

Loading

jdalton Apr 24, 2018 •

edited

Loading

devsnek commented Apr 28, 2018 •

edited

Loading

jdalton Apr 29, 2018 •

edited

Loading