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

support @std/esm #1618

Merged
merged 5 commits into from
Jan 8, 2018
Merged

support @std/esm #1618

merged 5 commits into from
Jan 8, 2018

Conversation

jamestalmage
Copy link
Contributor

This fixes support for @std/esm.

//cc: @jdalton

(opts.require || []).forEach(x => require(x));
(opts.require || []).forEach(x => {
if (/.*std[/\\]esm[/\\]index\.js$/.test(x)) {
require = require(x)(module); // eslint-disable-line no-global-assign
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Basically, we are making sure that we use @std/esm's require function instead of the standard one when we load the test file later in the file.

I am a bit surprised that this is necessary, since I figured @std/esm would install a require extension hook (via pirates or similar). @jdalton, am I mistaken here? Do you not implement a require hook via require.extensions['.js']?

Copy link
Contributor

@jdalton jdalton Dec 23, 2017

Choose a reason for hiding this comment

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

Since @std/esm is meant to be a production dependency, as well as a dev dependency, we can't just always overload the global require.extensions (the Node folks would flip-out, esp. since Lodash v5 will be using @std/esm).

If @std/esm is invoked through a CLI then it will hook into require.extensions, otherwise it produces its own loader instance for folks to use as you've done 👆. Whenever AVA requires @std/esm through the --require option the @std/esm loader is in CLI mode so will hook require.extensions. In this case, the thing preventing its use is the precompile check which dead-ends the load chain and prevents it from getting to @std/esm.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

precompile would only be short circuiting imports for tests, but those will have already used Babel to convert the import statements to require statements.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I poked around in the @std/esm codebase, and didn't see where you were actually hooking require.extensions (even in "CLI mode").

Copy link
Contributor

@jdalton jdalton Dec 24, 2017

Choose a reason for hiding this comment

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

precompile would only be short circuiting imports for tests, but those will have already used Babel to convert the import statements to require statements.

That's the only issue affecting @std/esm (the test files).

I poked around in the @std/esm codebase, and didn't see where you were actually hooking require.extensions (even in "CLI mode").

I think @std/esm might be OK with just having ababel: false or precompile: false option. That way it avoids any package specific sniffs and is something that can be applied for other uses/reasons.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK, so this is actually only a problem when Babel is configured not to transpile ESM modules. Setting babel:false does not actually disable Babel - we still apply a few transforms to the tests for power-assert support, and providing better errors for common misuses of the API.

Since we're always going to load Babel, precompile: false becomes a huge performance hit, as Babel just takes too long to load.

Copy link
Contributor

@jdalton jdalton Dec 24, 2017

Choose a reason for hiding this comment

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

OK, so this is actually only a problem when Babel is configured not to transpile ESM modules.

Correct. The user wanted to just use @std/esm which is where I pointed to #709.

we still apply a few transforms to the tests for power-assert support

power-assert ships with a UMD build (no Babel required). The babel-plugin-throws-helper could always be optional or could be written for acorn+magic-string or other lighter solutions.

Copy link
Contributor Author

@jamestalmage jamestalmage Dec 24, 2017

Choose a reason for hiding this comment

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

power-assert ships with a UMD build (no Babel required). The babel-plugin-throws-helper could always be optional or could be written for acorn+magic-string or other lighter solutions.

Interesting ideas. Power assert already has an acorn based transform, so the whole stack could share that.

Copy link
Contributor

Choose a reason for hiding this comment

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

@std/esm uses acorn+magic-string 😋

{
"cjs": true,
"esm": "js"
}
Copy link
Contributor

Choose a reason for hiding this comment

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

👆 You can shorthand to just "cjs" in the .esmrc file. In the next release you can use { "esm":"cjs" } as a shorthand for the above too.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Like "cjs"\n is the full contents of the file?

Copy link
Contributor

Choose a reason for hiding this comment

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

Ya, kinda gross but it works. You may want to wait for the other shorthand form.

@motss motss mentioned this pull request Dec 24, 2017
Copy link
Member

@novemberborn novemberborn left a comment

Choose a reason for hiding this comment

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

@jamestalmage just so I understand, this detects the @std/esm require and replaces the require() method we use for other "require" values?

Is there a remaining issue with how we load the transpiled test files, or how we transpile them to begin with?

@@ -27,7 +27,13 @@ globals.options = opts;

const serializeError = require('./serialize-error');

(opts.require || []).forEach(x => require(x));
(opts.require || []).forEach(x => {
if (/.*std[/\\]esm[/\\]index\.js$/.test(x)) {
Copy link
Member

Choose a reason for hiding this comment

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

This should start with [/\\]@std I think, to better match just @std/esm.

@jamestalmage
Copy link
Contributor Author

@novemberborn - The only other issue would be providing a way to bypass the main thread precompilation. In that case, the package sniffing I am doing wouldn't be needed.

@jamestalmage
Copy link
Contributor Author

It also replaces "require" for when we load the tests.

@billyjanitsch
Copy link
Contributor

(Apologies for the notification spam.) As the original reporter of standard-things/esm#197, I just want to express appreciation for everyone working on this. Always awesome to see OSS projects come together to support interoperability for users. Thanks y'all ❤️

Copy link
Member

@novemberborn novemberborn left a comment

Choose a reason for hiding this comment

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

@novemberborn - The only other issue would be providing a way to bypass the main thread precompilation. In that case, the package sniffing I am doing wouldn't be needed.

That's tracked elsewhere, but in any case it's entirely conceivable that users may want to use @std/esm while still using AVA's transpilations.

I think we should still tighten up the pattern match, and per @jdalton's comments could clean up the .esmrc file.

I know you're generally quite busy @jamestalmage (so thanks for chiming in with this PR!). Let me know if you'd like me to land it instead.

@jdalton
Copy link
Contributor

jdalton commented Dec 28, 2017

I just want to express appreciation for everyone working on this. Always awesome to see OSS projects come together to support interoperability for users. Thanks y'all

I was pretty floored by everyone jumping in to help out. It's such a pleasant surprise to have to rein in adjustments. Double thanks to y'all ❤️

@jdalton
Copy link
Contributor

jdalton commented Jan 6, 2018

Okay, @std/esm v0.19.0 is released 🎉 (which supports that shorthand mentioned above)!

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.

4 participants