Doesn't resolve with babel-plugin-module-resolver files in SFCs about vue-jest

[txantslusam]

Can confirm this bug.
I have a component, which import another one from different directory.
Importing this component with @ alias results in:
Cannot find module './src/components/partials/B' from 'A.vue'
But when i change import path to relative path, eg. '../../components/partials/B' it resolves correctly.
I added moduleNameMapper to Jest and configure babel alias.

[jacobmischka]

I believe it's slightly more complicated than that, because the module-resolver plugin is running, but the path resolution is incorrect.

In case anyone else stumbles across this, my solution was to use:

"moduleNameMapper": {
  "^\\./resources/assets/js/(.*)$": "<rootDir>/resources/assets/js/$1",
}

Or you could disable the babel plugin in env.test and then do what you said above, but that's currently a bit more confusing because of the weird way envs are merged in a json babelrc.

But I'm getting by just fine with this workaround, so no hurry! Thanks for the response!

[pmesgari]

Hi @eddyerburgh
As we spoke before, today I started working on debugging this issue. So far I have found out that using alias in .babelrc file will result in jest to look for the module as a hastePackage which results in the error. Without the alias nothing is being searched for as a hastePackage.

I am looking to find out what is a hastePackage in jest, I was wondering if you or someone else has any ideas on this?

[eddyerburgh]

I'm sorry I haven't been able to debug this.

A temporary solution is to use Jest moduleNameMapper. You can add this to your Jest config field:

"moduleNameMapper": {
    "^@/(.*)$": "<rootDir>/src/$1"
}

[eddyerburgh]

haste is a Facebook module resolver. They just moved Facebook away from it, so they may be planning to move Jest away too. https://github.com/facebookarchive/node-haste/tree/master

Thanks for looking into this by the way 😀!

[pmesgari]

No problem :)

What would you suggest to do about this?
I can go further into jest-resolve module to find a way to account for the error caused by
hastePackage, but with their future plan, it might not be the best.
Or is there a possibility somewhere to account for this error in the vue-test-utils?
Or before passing the path to jest-resolve, transform the alias into a relative path.

[tskimmett]

Just ran into this problem today. I was able to come up with a somewhat clean solution. My setup includes: babel, jest, babel-jest, vue-jest.

This is the relevant portion of my babel.config.js:

module.exports = function (api) {
	// Module Resolution
	const moduleAliases = {
		"^src/(.*)$": "./src/\\1",
		"^localization/(.*)$": "./src/localization/\\1",
		"^lib1(/(.*))?$": "../../Public/lib1/src/\\2",
		"^lib2(/(.*))?$": "../../Public/lib2/src/\\2"
	};

	if (api.env("test")) {
		// Jest requires all module aliases to be mapped relative to <rootDir>
		for (const [key, value] of Object.entries(moduleAliases))
			moduleAliases[key] = `<rootDir>/${value}`;
	}

	api.cache(true);
return {
	plugins: [...],
	presets: [...]
}

Without this, using the module aliases in SFCs did not work when running tests. The only entry in moduleNameMapper for Jest is the one mapping which Vue build to use.

Does anyone know if something like this should/could be automatically supported by vue-jest?. I would be happy to look at making a pull request if it seemed like something that made sense to automatically handle.

[lmiller1990]

Hi! I am the main one maintaining this project nowdays.

Is this still an issue? I'm guessing so - isn't the solution just to use jest moduleMapper? Not sure this is something vue-jest should be doing. vue-jest is just one part of the jest config.