Is the js.commonjs-core-modules-replacements module matching being overly agressive?

[lm-sousa]

I'm trying to execute Mocha under graaljs in "Java Bindings mode" (Context API).

Mocha expects a series of Node APIs I'm providing through the js.commonjs-core-modules-replacements option as per the documentation.

In mocha/lib/runnable.js there is the following import statement:
var utils = require('./utils');

One of the core modules I'm replacing is util. Somehow, graal perceives ./utils to be the same as util and imports the replacement module instead of the local Mocha file. (I know this because I overwrote FileSystem::checkAccess in order to see all files being probed by graal)

I tried searching for the code that handles the js.commonjs-core-modules-replacements option and figure out why this behaviour is happening with no luck.

[eleinadani]

The commonjs replacement option should just "replace" certain module names with the ones you provide, and it should not try to convert e.g. util to ./utils. Do you have a reproducer so that we can have a look?

[iamstolis]

I tried to reproduce this issue i.e. I tried to run a basic mocha test using graaljs. I admit that it was a challenge but I succeeded eventually.

I installed (using npm install) mocha package into /some/directory.

I installed some other packages to help me replace core Node.js modules: buffer, events, level-filesystem, level-js, levelup, memdown, os-browserify, path-browserify, sprintf-js, stream-browserify, tty-browserify, url, util. These packages are mostly the packages used by browserify (to replace core Node.js modules).

browserify-fs did not work well for me, but almost identical approach worked fine, i.e., I created /some/directory/fsMockup.js with the following content

// inspired by browserify-fs

const leveljs = require('level-js');
const levelup = require('levelup');
const fs = require('level-filesystem');
const MemDOWN = require('memdown');
const db = levelup(new MemDOWN());
module.exports = fs(db);

I used the following simple test-suite (placed it into /some/directory/myTestSuite.js)

it('should run this test', function() {
  console.log('Your test is running!');
});

I used the following script (placed in /some/directory/mochaViaGraalJS.js) to setup some global variables (or their mockups). Note that this is a simple proof of concept, not the best practice that should be used in production. The end of this script sets up mocha and tells it to run our test-suite.

// Setup/mockup some globals

var global = globalThis;
var Buffer = require('buffer/').Buffer;
var clearTimeout = function() {};
var process = {
  version: 'v18.14.1',
  nextTick(fn) {
    Promise.resolve().then(fn);
  },
  on() {},
  removeListener() {},
  listenerCount() {},
  browser: false,
  env: {},
  argv: [],
  stdout: {
    fd: 1,
    isTTY: false
  },
  stderr: {
    fd: 2,
    isTTY: false
  },
  cwd() {
    return java.lang.System.getProperty("user.dir");
  }
};
var sprintf = require('sprintf-js').sprintf;
console.log = function() {
  java.lang.System.out.println(sprintf.apply(this, arguments));
};

// Run mocha

var Mocha = require('mocha');
var mocha = new Mocha();
// add test files
mocha.addFile('/some/directory/myTestSuite.js');
mocha.run();

Finally, I use the following command line to execute the result. I am aware that you want to use Context API, not a command line but it should be trivial to rewrite this to Context API.

js --jvm --commonjs-require --experimental-options --commonjs-require-cwd=/some/directory --js.commonjs-core-modules-replacements=path:path-browserify,os:os-browserify,tty:tty-browserify,stream:stream-browserify,fs:/some/directory/fsMockup.js --unhandled-rejections=warn mochaViaGraalJS.js

and got

Your test is running!
  ✔ should run this test

  1 passing (49ms)

I used GraalVM CE Java17 22.3.1.