Inline require opts to process.argv

[mAAdhaTTah]

Description

From @jdalton:

Mocha does a nifty trick where it takes its mocha.opts file and inlines them into the process.argv arguments so @std/esm can detect itself. There's a bug open on nyc to add similar functionality. Ava should do this too 😋!

Source: standard-things/esm#89 (comment)

The reason this would be needed/helpful is so that std/esm parses the command line arguments to tell whether it should augment the module require to compile ESM.

May be related to #1393.

Config

If I have this:

{
  "ava": {
      "require": [
        "@std/esm"
      ]
  }
}

std/esm will be able to compile my app code's ESM in the tests without requiring babel.

Relevant Links

• Source issue: Running mocha programmatically standard-things/esm#89
• Related issue in nyc: Expand .nycrc to process.argv istanbuljs/nyc#660

[jdalton]

The relevant bit in Mocha's implementation is here.

[novemberborn]

We won't support -r in AVA's CLI flags, nor add additional flags to the workers.

You should be able to use node -r "@std/esm" ./node_modules/.bin/ava, or alternatively write a file that creates the loader and require that through AVA's package.json configuration. Though I can't figure out from the documentation whether that loader is then used for all modules.

[mAAdhaTTah]

Tried this: node -r "@std/esm" ./node_modules/.bin/ava; no dice w/ v0.8.3 of esm.

write a file that creates the loader and require that through AVA's package.json configuration

This sounds possible, but (I think) we would have to overwrite the global require function. I attempted (ava-esm.js):

// Nope
require('module').prototype.require = require('@std/esm')(module, { cjs: true, esm: 'js' });
// Nah
require('module').prototype.require = require('@std/esm')(module, true);
// Still no
require('module').prototype.require = require('@std/esm')(module);

Different errors with each one, but none of them work. Is this the right approach to take? Any other ideas?

[jdalton]

@novemberborn

You should be able to use node -r "@std/esm" ./node_modules/.bin/ava

AVA seems to be using its own loader require-precompiled

export var value = reset()
^^^^^^

SyntaxError: Unexpected token export
    at createScript (vm.js:74:10)
    at Object.runInThisContext (vm.js:116:10)
    at Module._compile (module.js:537:28)
    at Module._extensions..js (module.js:584:10)
    at extensions.(anonymous function) (/projects/esm/node_modules/require-precompiled/index.js:16:3)
    at Object.require.extensions.(anonymous function) [as .js] (/projects/esm/node_modules/ava/lib/process-adapter.js:100:4)

@mAAdhaTTah

// Nope
// Nah
// Still no

That's not the right approach. If the esm loader can be the entry point for all tests then you can do:

require("@std/esm")(module)("./testForAll.js")

but there is no way to enable global require overwriting with its programmatic API (that's a feature).

@novemberborn

It looks like AVA sends commands as JSON string arguments to its forked processes. I should be able to sniff them. Is this a standard thing or something AVA cooked up?

[jdalton]

It looks like patching @std/esm to sniff stringified params will enable @std/esm to hook in with:

"ava": {
  "require": "@std/esm"
}

but then it's running into AVA's built-in Babel use (AVA is transpiling the import/export). I tried to disable it with some Babel configs but not having any luck. Any guidance @novemberborn?

[mAAdhaTTah]

@jdalton Ava transpiles its test files by default, but not external files. I'm trying to use @std/esm for those so I don't need babel at all.

[jdalton]

@mAAdhaTTah I'm saying once @std/esm is patched to hook in with "require": "@std/esm" it still won't work because the test files are being handled by Babel via AVA. If there was a way to disable the "module":false transform for AVA then it might work. Which is why I'm asking @novemberborn if it's possible.

[mAAdhaTTah]

If AVA is handling transforming the test files via babel, shouldn't @std/esm just treat them like cjs files?

[jdalton]

The problem is that when AVA transpiles the test file

import envDelta from '../envDelta';

will transpile it to:

var _envDelta = require('../envDelta');
var _envDelta2 = _interopRequireDefault(_envDelta);
function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }

So because brookjs-cli/src/deltas/envDelta.js is handled by @std/esm its exported ias a regular cjs file without a __esModule property so Babel will treat it as { default: obj } which breaks the tests since envDelta is supposed to be a function not an object as { default: func }.

Update:

I made the cjs option of @std/esm add the _esModule property to its export and that fixed it with Babel unit tests.

[mAAdhaTTah]

I made the cjs option of @std/esm add the _esModule property to its export and that fixed it with Babel unit tests.

Awesome. We can close this out then, yeah?

[novemberborn]

Tried this: node -r "@std/esm" ./node_modules/.bin/ava; no dice w/ v0.8.3 of esm.

@mAAdhaTTah , I had assumed that would be propagated to the workers, but maybe not.

It looks like AVA sends commands as JSON string arguments to its forked processes. I should be able to sniff them. Is this a standard thing or something AVA cooked up?

@jdalton it's our own thing. Note that we do have a stalled PR that aims to forward remaining arguments to the workers, but they'd come after the filename argument so that wouldn't quite help with -r.

it's running into AVA's built-in Babel use (AVA is transpiling the import/export). I tried to disable it with some Babel configs but not having any luck. Any guidance @novemberborn?

It is possible to disable this, yes. You'd lose all other transforms though (currently not a problem with Node.js 8, but it'll hurt the compatibility of your tests with earlier versions). But we can find a way of running https://github.com/avajs/babel-preset-stage-4 without the module transform.

[jdalton]

It is possible to disable this, yes. You'd lose all other transforms though (currently not a problem with Node.js 8, but it'll hurt the compatibility of your tests with earlier versions).

Can you go into detail. I know some Babel presets like babel-env allow you to disable module transpilation with "module": false option. How does that map to AVA?

[dinoboff]

@jdalton to disable module transform you can try with @dinoboff/babel-preset-stage-4 (scoped package for this avajs/babel-preset-stage-4#8):

npm i @dinoboff/babel-preset-stage-4

And in package.json:

{
  "ava": {
    "babel": {
      "presets": [
        [
          "@dinoboff/stage-4",
          {
            "modules": false
          }
        ]
      ]
    }
  }

[novemberborn]

Can you go into detail. I know some Babel presets like babel-env allow you to disable module transpilation with "module": false option. How does that map to AVA?

@jdalton we currently do not have that option, but we should. @dinoboff helpfully opened avajs/babel-preset-stage-4#8.

Besides this detail, is there anything that prevents @std/esm from working with AVA? And has there been consideration for enabling the processing of all files via an environment variable?

[jdalton]

@novemberborn

Besides this detail, is there anything that prevents @std/esm from working with AVA?

I patched @std/esm so it works with Babel transforms using the "cjs":true option and the AVA require option. All good!

And has there been consideration for enabling the processing of all files via an environment variable?

That hasn't been brought up. I'd be concerned that deps of deps of deps using @std/esm would also trigger since they'd notice the environment variable too.