Skip to content

esm: Add support for pjson cache and main without extensions #18728

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.

Sign up for GitHub

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

Closed
guybedford wants to merge 13 commits into from
Closed

esm: Add support for pjson cache and main without extensions #18728

Changes from 1 commit
Commits
Show all changes
13 commits
Select commit Hold shift + click to select a range
f14420e
esm: support main without extension and pjson cache
guybedford Feb 12, 2018
adfe1ac
pr feedback
guybedford Feb 12, 2018
ebdb3cb
explicit isMain checks
guybedford Feb 12, 2018
5855e5c
loader setup promise tweaks
guybedford Feb 12, 2018
05c9941
further tweaks
guybedford Feb 12, 2018
2d6d4e6
c++ feedback
guybedford Feb 12, 2018
a06db2d
better todo for JSON parse failure
guybedford Feb 12, 2018
081aab4
invalid json handling todo
guybedford Feb 12, 2018
ed9df8a
naming adjustments, simplifications
guybedford Feb 12, 2018
8b4d85f
move PackageConfig into loader namespace
guybedford Feb 12, 2018
4468e2c
make PackageConfig consts
guybedford Feb 12, 2018
b4dc802
clean up emplace logic a little
guybedford Feb 13, 2018
9f7aabd
boolean aliasing
guybedford Feb 14, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
loader setup promise tweaks
  • Loading branch information
@guybedford
guybedford committed Feb 12, 2018
commit 5855e5ca839100fb8fb23d4b878e46ef61dc1708
54 changes: 30 additions & 24 deletions lib/internal/process/modules.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,29 +21,35 @@ function initializeImportMetaObject(wrap, meta) {
meta.url = wrap.url;
}

let loaderResolve, loaderReject;

@benjamingr benjamingr Feb 12, 2018

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

So, elaborating on what I wrote before:

let aResolve, aReject;
exports.loaderPromise = new Promise((resolve, reject) => {
  aResolve = resolve;
  aReject = reject;
});
trackedPromise.then(aResolve, aReject);

Can be written as:

let aResolve;
exports.loaderPromise = new Promise((resolve, reject) => {
  aResolve = resolve;
});
aResolve(trackedPromise);

@devsnek devsnek Feb 12, 2018

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

could also just use createPromise/promiseReject/promiseResolve, no?

@benjamingr benjamingr Feb 12, 2018

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

@devsnek that's technically true but I'm not sure it would help clean the code and that's an internal API - I doubt the cost of the extra closure here is worth it.

@apapirovski apapirovski Feb 12, 2018

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I haven't looked through this code at all, so take this with a grain of salt, but I recently did a lot of benchmarking on using the Promise constructor vs the internal createPromise/promiseReject/promiseResolve and the latter is definitely quite a bit faster.

But again, I don't know about the usage here, whether this is performance sensitive code, if these functions end up being user-land exposed, etc.

@devsnek devsnek Feb 12, 2018 •
edited
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

i just meant for readability heh, i was actually under the impression that the api was slower than the promise constructor

const loaderPromise = exports.loaderPromise = createPromise();
...
promiseResolve(loaderPromise, ESMLoader);

@benjamingr benjamingr Feb 12, 2018

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

@devsnek @apapirovski not allocating a closure and it being faster is actually why we have this API to begin with (as well as util.promisify). There's a bit of history involved but if it wasn't faster I'd be surprised. That said - this code does I/O and the impact of an extra closure isn't something we should optimize for.

@devsnek I think it makes the code easier for people more familiar with promises in core to read but overall I personally prefer standard to nonstandard when we have the choice.

Namely, there are subtle differences between promiseResolve and resolve in the promise constructor which I'd rather avoid in areas that are not performance sensitive. I don't feel strongly about it though.

exports.loaderPromise = new Promise((resolve, reject) => {
exports.setup = function() {
setInitializeImportMetaObjectCallback(initializeImportMetaObject);

let ESMLoader = new Loader();
const loaderPromise = (async () => {
const userLoader = process.binding('config').userLoader;
if (userLoader) {
const hooks = await ESMLoader.import(
userLoader, getURLFromFilePath(`${process.cwd()}/`).href);
ESMLoader = new Loader();
ESMLoader.hook(hooks);
exports.ESMLoader = ESMLoader;
}
return ESMLoader;
})();
loaderPromise.then(resolve, reject);

setImportModuleDynamicallyCallback(async (referrer, specifier) => {
const loader = await loaderPromise;
return loader.import(specifier, normalizeReferrerURL(referrer));
});

exports.ESMLoader = ESMLoader;
};
loaderResolve = resolve;
loaderReject = reject;
});

exports.ESMLoader = undefined;

exports.setup = function() {
setInitializeImportMetaObjectCallback(initializeImportMetaObject);

let ESMLoader = new Loader();
const loaderPromise = (async () => {

@benjamingr benjamingr Feb 12, 2018

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This isn't a great pattern and errors here are suppressed unless explicitly asked for

const userLoader = process.binding('config').userLoader;
if (userLoader) {
const hooks = await ESMLoader.import(
userLoader, getURLFromFilePath(`${process.cwd()}/`).href);
ESMLoader = new Loader();
ESMLoader.hook(hooks);
exports.ESMLoader = ESMLoader;
}
return ESMLoader;
})();
loaderPromise.then(loaderResolve, loaderReject);

setImportModuleDynamicallyCallback(async (referrer, specifier) => {
const loader = await loaderPromise;
return loader.import(specifier, normalizeReferrerURL(referrer));
});

exports.ESMLoader = ESMLoader;
};