Move some functions outside of the "create"?

The version of ESLint you are using. Not related

The problem you want to solve. Since the linting in typescript is proposed to change to eslint now (https://eslint.org/blog/2019/01/future-typescript-eslint), it’s a hot demand for some popular eslint rules to recognize the typescript token as well. Apparently, those ts-specific, slightly extended rules shouldn’t be in eslint repo but in typescript-eslint. However, even tough only 10% of the change is necessary, it’s a hard work to extend these rules. That’s because the utility functions are defined inside the create function and hence not able to be exported (see https://github.com/eslint/eslint/pull/11965). That means, a new rule need to copy & paste these utility functions before that 10% change can be added.

Your take on the correct solution to problem. Are we able to refactor these rule to export those utility functions when necessary?

Are you willing to submit a pull request to implement this change? https://github.com/eslint/eslint/pull/11965

[platinumazure]

Hi @fa93hws, thanks for the issue.

The biggest challenge to doing this is that in doing so, we have to make a tough decision: Do we consider this an expansion of the public API (in which case we are unable to refactor easily later on, and/or we would need to do semver-major releases more frequently)? Or do we not consider this an expansion of the public API (in which case, we would inadvertently break typescript-eslint and other consumers on semver-minor or semver-patch releases if we refactor some of the utility code).

Neither of these options sounds great to me. The fact is, at the moment, the ESLint core rules are not designed to be extensible. So if we’re going to make a change here, we need to do so thoughtfully.

[eslint-deprecated[bot]]

Unfortunately, it looks like there wasn’t enough interest from the team or community to implement this change. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to reach accepted status after 21 days tend to never be accepted, and as such, we close those issues. This doesn’t mean the idea isn’t interesting or useful, just that it’s not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.