jasmine / jasmine-npm

A jasmine runner for node projects.
MIT License
376 stars 145 forks source link

--reporter does not work with namespaced modules #199

Closed NicoAiko closed 1 year ago

NicoAiko commented 2 years ago

Version: jasmine@4.2.1 Operating System: Windows 10

This is a similar error to #196 if you ask me.

Likely the root of this problem

Due to loader.js in line 16 checking if the modulePath contains a path separator and for /, it tries to load the module using file:// protocol as (our) reporter contains a slash in its module name.

Line in question: if (modulePath.indexOf(path.sep) === -1 && modulePath.indexOf('/') === -1) {

Error message:

Error: Failed to load reporter module xxx/yyy
Underlying error: Error [ERR_MODULE_NOT_FOUND]: Cannot find module 'some absolute path'
// stack error stuff

Workaround:

Like in #196, it's possible to use "jsLoader": "require", but if possible that shouldn't be necessary.

Kagu-chan commented 2 years ago

Quick side note here: This behavior basicaly occurs when using namespaced node modules.

In our package.json we have:

{
  "scripts": {
    "test": "nyc ts-node node_modules/jasmine/bin/jasmine --config=jasmine.json --reporter=@namespace/jasmine-junit-reporter"
  }
}

The reporter= section causes the issue on our end.

sgravrock commented 2 years ago

Thanks @Kagu-chan .

I could take a crack at this myself, but I'm not aware of any publicly available reporters that are in namespaces. (I assume the reporters both of you are using are private, since you've both redacted the names or paths.) It would probably be better if someone who actually has this problem, and can therefore verify a fix, would submit a PR.

Kagu-chan commented 2 years ago

Hi @sgravrock

Thanks for the response - yes, we use a private / namespaced module. I think just checking for a module starting with @ would not be enough, as there is stuff like rxjs/operators (which doesn't matter here, just for sake of an example - it would still be not found) or aliased imports (which would turn the issue in the exact opposite direction).

May it be an option to load the package.json (if we get the data without any problems) and 'whitelist' modules to load them as we normally would?

I don't know which implications to performance or stability / false positives this would have though...

sgravrock commented 2 years ago

I think @NicoAiko has it right: the problem is that Jasmine incorrectly treats anything with a slash in it as a relative path. If that was fixed so that only import specifiers starting with ./ or ../ were treated as relative paths, everything should just work.