Add context.isFile for rules

[sindresorhus]

The version of ESLint you are using.

6.2.1

The problem you want to solve.

I have some ESLint rules that needs to know whether the linted code is a string or an actual file. Currently, I use context.getFilename() === '<input>' || context.getFilename() === '<text>' (see sindresorhus/eslint-plugin-unicorn#346).

Your take on the correct solution to problem.

Add a context.isFile property, so I don't have to check multiple internal filename placeholders.

Are you willing to submit a pull request to implement this change?

No

[kaicataldo]

This seems like a reasonable request to me. It would be nice to abstract those internal input placeholders away from rule authors.

[ilyavolodin]

I would be fine with adding a utility like that. But out of curiosity, could you provide an example of a rule that needs to know if it's linting a file or a string?

[sindresorhus]

This filename-case rule lints the filename of JS files, and this prevent-abbreviations rule prevents use of abbreviations in variables, properties, but also filenames.

[mysticatea]

• This is a core feature, so we need an RFC: https://github.com/eslint/rfcs#eslint-rfcs
• I'm wondering if isFile() is a good name because I'm not sure how it works if it's a valid filename but doesn't exist. For example, engine.executeOnText(code, "a-dummy-filename.js"). It's not a file but is a valid filename. For another example, engine.executeOnText(code, "/path/to/a/directory/").
  • This is related to Expose true filename to rules #11989. If a processor was given, context.getFilename() can return dummy filenames (code block names).

[sindresorhus]

I'm wondering if isFile() is a good name because I'm not sure how it works if it's a valid filename but doesn't exist.

Good point. I don't think it should be concerned with whether it's a valid filename or existing file. It should only indicate that the filename option / --stdin-filename was used. How about .hasFilename?

[eslint-deprecated]

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.

[sindresorhus]

@mysticatea I can do a RFC, but it would be good to get some of the open questions here resolved first.

[kaicataldo]

@mysticatea does the comment above address your concern?

[mysticatea]

I'm sorry that I have lost track on this issue.

hasFilename sounds better, but I still have a concern technically.

I guess that the Linter class does make the value of hasFilename from whether filename option was given or not. But in fact, CLIEngine#executeOnText() method gives <text> as filename to Linter instance if users didn't give filename option to the CLIEngine instance.

And if we consider eslint/rfcs#35 (it returns undefined if cwd was not given) and #11989 (it has been requested to return the actual filename), I think that it's the best if we add the API that retrieves the actual filename and it returns undefined when the actual filename was not given.

[eslint-deprecated]

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.

[kaicataldo]

@sindresorhus Does @mysticatea's response clarify things? Want to make sure this doesn't get auto closed again :)

[eslint-deprecated]

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.