Call for maintainers

[tleunen]

Hey there,

As you may have noticed, I'm way less active in this project than I used to be in its early days. The main reason to that is because I'm not an active user of the plugin anymore so finding the time and energy to contribute to it is harder.

I would like to let people contribute more and ideally hand over the project to someone else which will take care of it and keep maintaining it, and hopefully fix the couple issues around Babel 7 and React Native that seem to be present in the recent build.

Please, let me know if you're interested and we can discuss about it, with @fatfisz as well since he was a great contributor.

[Andarist]

Hi! I might help maintaining the repo "passively" if you want. I could monitor PRs and help them get merged in, potentially also providing emergency fixes in case something gets really broke. I don't have time to maintain issues though.

[fatfisz]

Thanks for your kind words, @tleunen. I'm also looking at this project much less now, especially since it just works ™️ for me. The biggest issues right now are two things that, frankly, I don't want to get into:

1. The React Native thing is people just piling complaints without an initiative to take matters into their hands. This is just a sign of a broader problem in the open source "community".
2. Babel 7 issues is something I didn't experience. At my job we've migrated to Babel 7 without a problem and the plugin just worked, so there's that.

There are some problems that are inherent to the way caching works in most places, and the plugin can't deal with them as it is built right now: eg. renaming src/components/Button.js to src/components/Button/index.js will break a src/components/Button import (unless no cache is used). The only solution I see that doesn't involve turning cache off is to use configuration for each tool separately: in my case both Webpack and Jest won't have a problem with that. For linting purposes I wrote a custom ESLint plugin that handles sorting and has autofixing capabilities.

In short: I might be migrating away from the plugin too, it was nice while it lasted, but the time to move on approaches.

[jonlu]

@fatfisz Just found this plugin, sad. I'm working on a package that doesn't get webpacked (only parsed via babel). What're you migrating away to if I may ask?

[fatfisz]

If you're using only Babel, then this plugin is still one of the best things you can get.

But otherwise most bundling/testing tools already provide their own means of resolving paths that don't suffer from the cache problem. With Rollup it's possible viarollup-plugin-node-resolve. Parcel also allows configuring path resolver.

I won't be migrating to some other plugin - I'll just stick to config in Webpack & Jest.

It's just a shame that Node.js' path resolution algorithm doesn't handle something like ~/path/to/project/file, which would cover all of my usecases. I just want absolute paths wrt the project root, dammit 😭

[0xdevalias]

If you're wanting to use something like this in jest, the following config options may be useful:

• https://jestjs.io/docs/en/configuration#roots-arraystring (roots)
• https://jestjs.io/docs/en/configuration#resolver-string (custom resolver function)
• https://jestjs.io/docs/en/configuration#moduledirectories-arraystring (relative, searches ancestors)
• https://jestjs.io/docs/en/configuration#modulepaths-arraystring (absolute, doesn't search ancestors)
• https://jestjs.io/docs/en/configuration#modulepathignorepatterns-arraystring
• https://jestjs.io/docs/en/configuration#modulefileextensions-arraystring
• https://jestjs.io/docs/en/configuration#modulenamemapper-objectstring-string (can be used for aliases)

I also did a bit of deep dive/exploration in #375 to try and figure out why jest-resolve wasn't being hooked, so that ticket shows how you could implement a custom resolver entirely in jest.

[zeckdude]

@fatfisz I just noticed your comment and think I may be experiencing the same issue:

It's just a shame that Node.js' path resolution algorithm doesn't handle something like ~/path/to/project/file, which would cover all of my usecases. I just want absolute paths wrt the project root, dammit 😭

I created the following settings:

"plugins": [
    [
      "module-resolver",
      {
        "alias": {
          "~": "./src",
          "#serviceFixtures": "./src/services/__fixtures__"
        }
      }
    ]
  ]

This allows me to import everything based on the root like so: import { User } from '~/models/user'. This works great when I run my tests, but once I fire up the app I am getting a whole bunch of errors like this: Error: Cannot find module '~/models/user'.

Are you saying what I am trying to do is not possible? Is there a workaround?