[unbound-method] don't suppress errors thrown by base rule

[G-Rath]

When I originally added our extension to unbound-method, I wanted to allow people to be able to enable it in shared ESLint configs themed around Jest rather than JavaScript or TypeScript i.e. so you could use such a config in projects regardless of if they were using TypeScript without needing to do anything extra.

We achieve this in two ways:

1. We internally handle MODULE_NOT_FOUND errors when attempting to require the rule:
   

   eslint-plugin-jest/src/rules/unbound-method.ts

   Lines 25 to 43 in 78a7141

   	const baseRule = (() => {
   	try {
   	// eslint-disable-next-line @typescript-eslint/no-require-imports
   	const TSESLintPlugin = require('@typescript-eslint/eslint-plugin');
   	return TSESLintPlugin.rules['unbound-method'] as TSESLint.RuleModule<
   	MessageIds,
   	Options
   	>;
   	} catch (e: unknown) {
   	const error = e as { code: string };
   	if (error.code === 'MODULE_NOT_FOUND') {
   	return null;
   	}
   	throw error;
   	}
   	})();

2. We swallow any errors thrown by the rule itself when attempting to create it:
   

   eslint-plugin-jest/src/rules/unbound-method.ts

   Lines 45 to 53 in 78a7141

   	const tryCreateBaseRule = (
   	context: Readonly<TSESLint.RuleContext<MessageIds, Options>>,
   	) => {
   	try {
   	return baseRule?.create(context);
   	} catch {
   	return null;
   	}
   	};

I think 2. is actually the wrong thing to do because notably it includes the "project property not specified" error that is thrown if you attempt to use the base rule without sufficient configuration for the parser services to be generated, without which the rule cannot work.

I don't think it would be a breaking change, but if we do a new major in the near-future we might as well include it at the same time - I will also be trying this on some of my projects at work to check I've not forgotten anything (tbh though I can't remember why I didn't think checking that @typescript-eslint/eslint-plugin was sufficient)

For reference, we do have a test that covers the current behaviour which'd effectively be inverted by this:

eslint-plugin-jest/src/rules/__tests__/unbound-method.test.ts

Lines 186 to 203 in 78a7141

	describe('when "project" is not set', () => {
	const ruleTester = new ESLintUtils.RuleTester({
	parser: '@typescript-eslint/parser',
	parserOptions: {
	sourceType: 'module',
	tsconfigRootDir: rootPath,
	},
	});
	ruleTester.run(
	'unbound-method jest edition without "project" property',
	requireRule(false),
	{
	valid: validTestCases.concat(invalidTestCases.map(({ code }) => code)),
	invalid: [],
	},
	);
	});

cc @SimenB @bradzacher for thoughts

[github-actions]

🎉 This issue has been resolved in version 27.0.0-next.2 🎉

The release is available on:

• npm package (@next dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[github-actions]

🎉 This issue has been resolved in version 27.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀