Skip to content
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.

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

feat(agoric-cli): Support Node.js ESM deploy scripts #3686

Merged
merged 2 commits into from
Aug 16, 2021
Merged

feat(agoric-cli): Support Node.js ESM deploy scripts #3686

merged 2 commits into from
Aug 16, 2021

Conversation

kriskowal
Copy link
Member

refs: #527

This adds support for Node.js ESM deploy scripts, allowing dapps to be created
or refactored using Node.js ESM instead of the standardthings/esm emulation.

To test this feature, I created a nesm branch of the dapp-fungible-faucet
dapp that was converted to Node.js ESM with "type": "module" in
package.json and verified through a console log that agoric deploy chose to
use the Node.js ESM implementation. For good measure, I added a temporary
useless reference to import.meta.url, which is not properly emulated by -r esm.

This necessitated an additional feature to agoric init, to specify the
branch to use from the template dapp.

Copy link
Member

@michaelfig michaelfig left a comment

Choose a reason for hiding this comment

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

LGTM, modulo one little rename.

Comment on lines 251 to 252
: // eslint-disable-next-line import/no-dynamic-require
require(modulePath);
Copy link
Member

Choose a reason for hiding this comment

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

Please do the renaming needed to make this suggestion possible:

Suggested change
: // eslint-disable-next-line import/no-dynamic-require
require(modulePath);
: esmRequire(modulePath);


// Use Node.js ESM support if package.json of template says "type":
// "module".
const packageFile = pathResolve('package.json');
Copy link
Member

Choose a reason for hiding this comment

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

Oh, another thing: the package.json should be searched starting from the moduleFile, since it is possible that the moduleFile is in a different subpackage than the top-level package.json.

Copy link
Member Author

Choose a reason for hiding this comment

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

I resolved this by bringing in a utility in compartment mapper that searches for the package.json above any file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants