GitXplorerGitXplorer
l

vale-test

public
0 stars
0 forks
0 issues

Commits

List of commits on branch main.
Verified
b2d254bfcc1799cdc3027819588abf7435d60e5a

Update erroneous output for new test case

llee-dohm committed 4 years ago
Verified
072b130182e2483c5f53d22b535342edadfb7dd2

Add additional test case

llee-dohm committed 4 years ago
Verified
c3bc4457aba85fe73dd773b2656d6086561e7446

Add additional TokenIgnore for Liquid object references

llee-dohm committed 4 years ago
Verified
757f8d8974e49251b0a39e1809753b2c3447151a

Add passing test and explanation

llee-dohm committed 4 years ago
Verified
085002c9b79ab95e25f00e5580513d29ce78cd9a

Clarify the behavior

llee-dohm committed 4 years ago
Verified
eb16aee8691a6ed739b6789837205f3f4ec97c39

Add background explanation for the bug

llee-dohm committed 4 years ago

README

The README file for this repository.

Vale Linter Bug Reproduction

I'm running into what appears to be a bug with vale. This repo contains a minimal repro for the bug.

Explanation

We use Liquid tags in our Markdown documentation to dereference things like product names. I've configured vale to ignore any inline text in Liquid tags {% ... %} via the TokenIgnores configuration option. And, most of the time, that seems to exclude things. But occasionally, it appears that what shows up inside the Liquid tags is getting linted anyway? 🤷‍♂️

Repro Steps

  1. Clone the repo
  2. Execute the command: vale test.md

Expected: No errors
Actual: 3 error (see Erroneous Output below)

Notice that the first Liquid tag containing the text is flagged as an error, but the second identical Liquid tag on the same line is not.

Erroneous Output

 test.md
 1:169  error  Use 'GitHub' instead of         Vale.Terms
               'github'.
 3:65   error  Did you really mean 'api'?      Vale.Spelling
 3:69   error  Did you really mean 'url'?      Vale.Spelling

Passing case

In the branch named passing you can see that changing the accept.txt term from GitHub to FooBar and the Liquid tags from {% data variables.contact.github_support %} to {% data variables.contact.foobar_support %} does not reproduce the problem. It passes with zero errors detected.