Adding the location of the parsed file in the start-event
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 3.3k
- Forks
- 474
- Avg merge
- 1d 11h
- Merged PRs (30d)
- 12
Description
Is your feature request related to a problem? Please describe.
Introducing HTMLHint to legacy code is quite tricky. You can either disable all failing rules or ignore the file for all HTMLHint rules.
It is impossible to implement a ratcheting system where I can prevent new commits from having faults while systematically ignoring the existing faults.
This is especially the case for custom rules, where very specific problems can be detected at a very late stage and require huge amounts of labor to fix.
Describe the solution you'd like
There must be some way to retrieve the currently parsed source code location.
With that one can add an ignored source code location list to each of the rules and ignore the specific pages.
Currently the start-event looks like this:
{
pos: 0,
line: 1,
col: 1,
type: 'start'
}
Adding the source code location would allow that implementation:
{
pos: 0,
line: 1,
col: 1,
type: 'start',
url: '/home/text.html'
}
Describe alternatives you've considered
I tried checking every event if they contain such information but nothing was found.
I am unaware of any Node.js specific function or object to retrieve that information,
which file HTMLHint is currently working on.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the parser path that emits the start event and how the current file input reaches it. Run the existing parser or event tests, then verify that parsing a named file exposes its source location on the event while preserving the current position fields and existing consumers.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100