Dependency-cruiser: Feature request: add support for babel-plugin-module-resolver

[atav32]

Context

babel-plugin-module-resolver is an alternate way to alias module paths. The syntax is a bit simpler than Webpack's alias option.

Expected Behavior

Would be awesome if dependency-cruiser could follow these aliases import paths.

Current Behavior

Currently, any import path aliased with babel-plugin-module-resolver is unresolvable.

Possible Solution

The module path mapping is pretty straight forward in the Babel config – it's just alias name to relative path.

Considered alternatives

Could move our module aliases from our Babel config to our Webpack config

[sverweij]

Hi @atav32 thanks for raising this issue.

Babel aliases (as well those in use in parcel and rollup) have been on the backlog for some time, but other things got priority first. I've moved it up a bit. Integrating it into dependency-cruiser will be an interesting challenge (even given the module resolver api) - I have a few ideas on how to approach it.

Out of curiosity: What is the reason to use babel-plugin-module-resolver over options e.g. bundlers offer for aliases?

It seems babel-plugin-module-resolver is moving into legacy land - a.o. because of the advent of alternatives
like aliases in tsconfig (typescript), and options bundlers (like webpack) offer:

• there seems to be no active maintainer (a.o. because the maintainers themselves don't use it anymore (tleunen and fatfisz) and there's a.t.m. nobody willing to jump in)
• as a consequence there's quite some open issues (not all bugs b.t.w. but a lot of them can be closed by simple triaging, which doesn't seem to happen)
• some projects mentioned in the readme moved on as well e.g. algolia instantsearch and next.js don't use it anymore.

[tpucci]

I personally use babel-plugin-module-resolver with React Native. It works great !
I recommend you set up paths in tsconfig.json in association with babel-plugin-module-resolver. It seems dependency-cruiser supports it 👍🎉

[atav32]

@sverweij thanks for pointing out that babel-plugin-module-resolver isn't the most active project. There isn't an overriding reason that we're using babel-plugin-module-resolver. Just a legacy decision that our team inherited.

I'll take a closer look at Webpack's alias option.

[sverweij]

hi @atav32 & @tpucci thanks again for bringing this to my attention.

TL;DR The next version of dependency-cruiser will have babel support (including the plugin/ preset ecosystem) - also see the linked PR (#304 ☝️ ).

=> I'd love to hear any feed back on how it works for you. I've published with the beta tag on npm as [email protected]

rationale

@tpucci's remark made me realise there's use cases for having a babel plugin taking care of path aliasing. There might be more than these, but they're already enough to warrant support in dependency-cruiser:

• You might not have a bundler in your tool chain when you're not developing for the web but for e.g. electron or atom (and react native, I guess?).
• You might not be in a position to use TypeScript (yet or at all)

Next to that: dependency-cruiser uses acorn, and acorn only implements TC39 stage 4. If you're using babel you likely do this because you want to use stuff from earlier stages, like export * as flakes from 'snowdash'. In order to enable you to use dependency-cruiser on that as well it'll have to grow babel support too.

[sverweij]

From the emoticons on the previous comment I infer it works well for you?

I've added some tweaks to make it easier to use and configure and published it as [email protected] - likely it'll be part of the next release (which follows in the coming days).