Import aliases breaks references required for mocking

[hugoaboud]

I'm implementing tests on my application using adonis-jest, which handles the Transformer logic used by Adonis along with jest.
It has been working so far. The issue below relates specifically to mocking.

The way the transformer works apparently breaks deep references from the modules, so mocked modules don't share the scope of modules imported using aliases.

Apparently, when importing through the alias, the module no longe shares a reference to the original module:

import ControllerA from "../app/Controller";
import ControllerB from "App/Controller";

console.log(ControllerA == ControllerB); // false

If you mix both syntaxes (with and without aliases) through the application, mocked tests might break without an apparent cause. This is a pitfall, but could be avoided by double-checking imports.

The real problem appears when trying to mock a method from within a node dependency. As described on the issue repository:

1. There's a custom NPM package called crud-lib, added as dependency to my adonis application app
2. crud-lib exports a Service class, with a request method
3. app has a Controller, which imports and uses crud-lib/Service
4. When trying to test Controller:
   a. I mock the implementation of Service.prototype.request, also imported as crud-lib/Service
   b. The Controller prototype returned by App/Controller apparently doesn't share the mocked Service.
   c. The Controller prototype returned by ../app/Controller does, so it works.

This means I'm not able to use aliases if I intend to use mocks, which feels like a bad decision.

The one thing I don't get is why the Service prototype is different for the Controller imported with and without alias. Does the Adonis Transformer creates a "deep cache" of the required modules?

Any thoughts would be appreciated.

[thetutlage]

I see this as more of an issue with the Node.js require cache. The first import ../app/Controller uses a relative path and the App/Controller gets transformed to an absolute path /root/some-folder/app/Controller and Node.js require cache treats them as two separate modules.

The only solution I can think of is to not mix import styles. However, I am open to suggestions, if this can be improved

[hugoaboud]

I ran some tests on the issue repository and wasn't able to reproduce the behaviour you've mentioned:

• Node v14.16.0

import ControllerA from "/home/aboud/adonis-jest-mock-issue/app/Controller";
import ControllerB from "../app/Controller";
import ControllerC from "App/Controller";

console.log(ControllerA); // [class Controller]
console.log(ControllerB); // [class Controller]
console.log(ControllerC); // [class Controller]
console.log(ControllerA == ControllerB); // true
console.log(ControllerB == ControllerC); // false
console.log(ControllerA == ControllerC); // false

From your description I was expecting the first comparison to also fail.
It also applies to the issue I'm having, where the Service prototype remains the same regardless of absolute/relative imports, but breaks using Adonis alias.

console.log(new ControllerA().service.constructor); // [class Service]
console.log(new ControllerB().service.constructor); // [class Service]
console.log(new ControllerC().service.constructor); // [class Service]
console.log(new ControllerA().service.constructor == new ControllerB().service.constructor); // true
console.log(new ControllerB().service.constructor == new ControllerC().service.constructor); // false
console.log(new ControllerA().service.constructor == new ControllerC().service.constructor); // false

Apparently this means that adonis aliases have their own scope, and everything imported through the alias, including nested imports, belongs to this scope.

I have found a workaround, which is forcing the node_modules/crud-lib import through Adonis alias on my test file:

...
"aliases": {
   ...
    "CRUD": "node_modules/crud-lib"
  }
...

// WithAlias.test.ts
import Controller from "App/Controller";
import Service from "CRUD/Service";

It still breaks with relative/absolute imports, but they are a bad practice anyway.
From my understanding, if I use alias imports through the application, i'm able to keep importing the dependency as icertus-crud anywhere.
When the test suite starts and Controller is imported by jest through the alias, i'm assuming it requires icertus-crid/Service at the "adonis scope". Then, in order to mock Service from my test file, I import it using the alias-to-package and it mocks the module on the right scope.

I can't evaluate how far this issue reaches beyond mocking. I've been using Adonis for a lot of stuff and this was never a concern. The workaround above has minimal impact on our workflow and apparently works, however I'd like to make sure my reasoning is valid.