Unmaintained, messy and out of date. Can we fix this?

[unconfident]

Here's a short recap of what's been going on:

babel-root-import has ben unnamed to babel-plugin-root-import about a year ago.

Since then readme and the code of this module has been partially updated, but that only resulted in a inconsistent state where some files refered to the old name, others to the new one, and even different lines within the same file were looking for two different names. While it's still depending on the old version of the plugin.

After that @bingqichen tried to fix it in his fork and snatched a perfect npm name for it - eslint-import-resolver-babel-plugin-root-import. Unfortunately his fork doesn't work properly either. There were some changes in babel plugin's helper.js and it only works correctly when file is included by prefix from the top directory of the project.

Then there was another fork - eslint-import-resolver-babel-root-import-fixed which fixes some of the issues and works, but still relies on the old version of babel plugin internally. And differences in eslint import resolver and babel plugin names can potentially still confuse some people

Now I'm considering publishing my fork to the NPM too...

What else? npm test breaks on ESLint check on current master. Thanks to #2 abscense of package.json crashes execution; package.json has highter priority than .babelrc, while Babel does the opposite when looking configuration up.

---

So I fixed the code part, pull requests submitted. But we still have like 3-4 different names to deal with and it would be nice to elliminate the confusion. What I'd like to suggest is:

1. Update dependencies, stick to babel-plugin-root-import everwhere for consistency 1.1 Merge my pull requests in order: #11, #12 (optional) 1.2 Maybe rename repository. Github makes it practically painless for other people 1.3. Ask @bingqichen nicely to give you the npm name with plugin- in it, publish under that name 1.4. Update readme of the eslint-import-resolver-babel-root-import package on npm to direct people to a new name.
2. Configure CircleCI. I'm only assuming it's being used because condition-circle is listed in package.json, but then there are also mocha and chai listed in devDependencies that aren't even used so that might be left overs. You will probably need #13 if you gonna use CircleCI V1
3. Cleanup: 2.1 Close #10, maybe #8 too if #12 is merged 2.2 Port #9 if needed and merge, because it's a nice feature,
4. For the future: 3.1 Add support for env option of .babelrc 3.2 Consider resolving alias suffixes themselves instead of changing working directory in getConfigFromBabel 3.3 Babel 7 will allow .babelrc.js, plugin name could become resolved path to the module. It's too early for this now, but this is something that should be supported when the time comes

[bingqichen]

@unconfident Thank you for finding and fixing more problems, I can unpublish my npm package when you are ready to release, but you konw unpublish is only allowed with versions published in the last 24 hours. Anyway, I will try to do this. If unsuccessful, I will guide the user to use your published package.

[unconfident]

@bingqichen there's no need to unpublish your package, transfer of package name can be done via granting rights to npm package to other people with following command

npm owner add <username> <package>

It's described on Package Name Disputes page of NPM site.

Considering for how long there hasn't been any activity on this repo I honestly don't think anybody cares anymore. I was going to wait for few days or a week since the moment of posting this issue and if nobody would reply by then I planned to contact you on behalf of that package name

Alternatively I can submit pull request to your fork and we continue from there

[unconfident]

when file is included by prefix from the top directory of the project.

Should have spent time proofreading it. What I meant by that is that it would only work properly if file from which other file has been required is located at the top directory of the project.

Because transformRelativeToRootPath started to return relative path (relative to project root) since 5.0.0 of babel plugin and eslint-import-resolver-node tried to resolve it from the context of current file. Which only matched when said file was at the top directory.

[bingqichen]

@unconfident npm add owner done. But I misuse removed myself...

[unconfident]

So I guess we're continuing with a fork for now. I'm fine with it.

@bingqichen thanks for the effort, and I've added you back so now you and me both listed as owners.

I'm going to publish my version as 1.0.1 today under that package name and will give you write access to repository too. Does it sound good for you?

[bingqichen]

@unconfident Wow, congratulations for you, I'm looking forward to it~