[6.0.0-alpha.1] `RuleTester` fails tests if `parser` property is a package name

From https://github.com/benmosher/eslint-plugin-import/issues/1362 From https://travis-ci.org/benmosher/eslint-plugin-import/jobs/533124402

Tell us about your environment

• ESLint Version: 6.0.0-alpha.1
• Node Version: 10.15.3
• npm Version: 6.4.1

What parser (default, Babel-ESLint, etc.) are you using?

n/a

Please show your full configuration:

n/a

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

Use RuleTester with parser option with babel-eslint. (e.g., eslint-plugin-import:/tests/src/rules/default.js#L31)

What did you expect to happen?

No errors.

What actually happened? Please include the actual, raw output from ESLint.

The test failed with “Parsers provided as strings to RuleTester must be absolute paths.”

Are you willing to submit a pull request to fix this bug?

Yes.

---

I think that RuleTester should allow package names (maybe it loads it relative to CWD).

Also, the Migration Guide must describe this change.

[mysticatea]

Thank you for the explanation.

But, my position is different. Because to use file paths for parser config is a pretty rare case (probably only we are). For 99.99% of users, parser is packages such as babel-eslint, vue-eslint-parser, @typescript-eslint/parser. and etc. Not a file path. Therefore, disallowing a package name would be a surprising behavior.

I think that good design is “people can do the most popular use case easily, and can do rare cases with detailed way.” I believe we should allow a package name and show a understandable error message for rare cases (E.g., '${parser}' was not found on '${cwd}'. Make sure the package to be installed or use an absolute path with 'require.resolve()'.). The current behavior seems to enforce annoying to users by afraid of pretty rare cases.

[not-an-aardvark]

The current behavior is intentional because it’s not clear where packages should be loaded from with RuleTester. I suppose the CWD works, but it could be confusing because projects using RuleTester might be dependencies of the user’s project, so they can’t guarantee that their dependencies will be loadable from the CWD. It seems like it would be safer to require an absolute path so that users use require.resolve to avoid the ambiguity.