Expose true filename to rules
See original GitHub issueThe version of ESLint you are using.
6.0.1
The problem you want to solve.
This. Some rules, like eslint-plugin-import’s no-unresolved, need to know the true path of the current file, not a path that’s been potentially assembled using a processor’s named code block.
Your take on the correct solution to problem.
I’m not entirely sure, but perhaps a new option to context.getFilename()
to return the true path rather than the one potentially created from a processor’s named code blocks.
Are you willing to submit a pull request to implement this change?
Yes.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:7
- Comments:50 (40 by maintainers)
Top Results From Across the Web
Naming Files, Paths, and Namespaces - Win32 apps
The following fundamental rules enable applications to create and process valid names for files and directories, regardless of the file system:.
Read more >Validate a file name on Windows - java - Stack Overflow
This solution will only check if a given filename is valid according to the OS rules without creating a file.
Read more >`.gitlab-ci.yml` keyword reference - GitLab Docs
Documentation for GitLab Community Edition, GitLab Enterprise Edition, Omnibus GitLab, and GitLab Runner.
Read more >Linux / UNIX: Rules For Naming File And Directory Names
In short, filenames may contain any character except / (root directory), which is reserved as the separator between files and directories in a ......
Read more >Rules | Bazel
This defines a kind of rule named example_library . The call to rule also must specify if the rule creates an executable output...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Option 2,
getPhysicalFilename()
, works for me.This should be reopened; it affects the plugin ecosystem.