ts-jest fails to import .ts modules from outside project root

Created on 23 Nov 2017  路  17Comments  路  Source: kulshekhar/ts-jest

  • Issue

ts-jest throws an error whenever a test utilizes a module from outside the project root.

ReferenceError: Unknown plugin "transform-es2015-modules-commonjs" specified in "base" at 0, attempted toresolve relative to "/home/colin/localdev/ts-jest-error/common"

      at node_modules/babel-core/lib/transformation/file/options/option-manager.js:180:17
          at Array.map (<anonymous>)
  • Expected behavior

TS files should be correctly imported even from outside the project.

  • Link to a minimal repo that reproduces this issue

https://github.com/colinskow/ts-jest-transform-error

cd main && npm install && npm test

Most helpful comment

Anyone know any more recent updates on this issue? I know Babel 7 is released now.

All 17 comments

I was able to reproduce this issue but I'm not sure if this is a bug in ts-jest.

What's happening is that when ts-jest tries to process common/index.ts, it can't find the dependencies because the context for the execution is set to the common directory.

Here are a few quick workarounds:

  • Create a symlink to the main/node_modules directory in either a common parent directory or in the common directory
  • Install the dev dependencies in either a common parent directory or in the common directory

Is this a viable option for you?

I would expect ts-jest to behave exactly as a project that is compiled with TSC and tests run on the JS version. The tests run fine when I build and run the generated JS.

Should the execution context not be the cwd the command is run from instead of the directory of each file?

In my case "common" is shared by several projects, and I prefer to use the node_modules of whatever project I am building at the time. I could use symlinks as a temporary workaround but it is not ideal.

I would expect ts-jest to behave exactly as a project that is compiled with TSC and tests run on the JS version

I would too. It's just that I'm not sure what's causing this. ts-jest doesn't do anything explicitly to modify the default tsc behavior.

The tests run fine when I build and run the generated JS.

It would be very helpful if you could have this version as a branch on the linked repo. Would that be possible?

Should the execution context not be the cwd the command is run from instead of the directory of each file?

ts-jest doesn't pick up the file. It is simply given the contents of the file by Jest. This may or may not have something to do with this issue. That's why I'm interested in seeing how the JS version works with Jest.

In my case "common" is shared by several projects, and I prefer to use the node_modules of whatever project I am building at the time.

I understand this use case as I do it too! I just do it the reverse way - I create symlink to the common directory in each of my project that uses it.

I updated the repo on the same branch so you can run npm run build && npm test to test the ts and JavaScript build at the same time. JS passes, TS fails.

I did some research and figured out this is a known bug in Babel which has been fixed, but since it is a breaking change will be available in Babel 7. The choices are to upgrade to [email protected] now or wait for the stable release.

I suggest keeping this issue open until the upgrade has been integrated and tested.

Interestingly enough, babel 7 has built-in typescript support which might make ts-jest obsolete. Let's keep this open and see what happens.

By the way, is there a specific reason that ts-jest uses Babel instead of vanilla TSC? Or was that a decision made within Jest?

We use both. Babel is not used to transpile type-script but as a postprocessing step, to handle some import stuff and e.g. hoist "jest.mock" calls.

Anyone know any more recent updates on this issue? I know Babel 7 is released now.

I still have a similar issue with this. With babel-loader version 7.1.1.

babel 7 is still in beta. Either way this seems like something we should fix on our end.

Hi: I also meet this issue today and finally find that set "allowSyntheticDefaultImports": false, solved it for me as a workaround.

@lyy011lyy Works for me too.

I also had to set moduleDirectories in my jest config to something like this:

"moduleDirectories": [
    "node_modules",
    "main/node_modules"
],

I have similar issue.

screen shot 2018-07-11 at 13 17 36

As you can see, when I'm running tests the "base-contoller.ts" cannot find module "../../../submodule/response" with typings file.
HOWEVER if typings file consists only from one interface, f.e.

export interface Response<T> {
    data: T;
    metadata?: any;
}

then tests pass.

screen shot 2018-07-11 at 13 24 10

(This error after passing tests still unknown for me :))

In a real application "submodule" dir is actually git submodule directory.

Link to a minimal repo that reproduces this issue: https://github.com/LogansUA/jest-import-error

Can anybody suggest something?

@LogansUA I think your issue is not related to this. Problem is probably with importing from .d.ts files, because it works when you rename it to index.ts

@josduj Should I create new issue? Or maybe you can suggest some way to fix it?

@colinskow updating jest and ts-jest (npm i jest ts-jest) in your minimal repo does fix the issue

@huafu npm i jest ts-jest

Was this page helpful?
0 / 5 - 0 ratings

Related issues

remcohaszing picture remcohaszing  路  4Comments

ozum picture ozum  路  4Comments

stephenotalora picture stephenotalora  路  3Comments

masters3d picture masters3d  路  4Comments

Slessi picture Slessi  路  3Comments