fix: add more info to attr value / statement validity

[DylanPiercey]

No description provided.

[changeset-bot]

🦋 Changeset detected

Latest commit: a11c1f1

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
htmljs-parser	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[coderabbitai]

Walkthrough

The pull request adds a new changeset entry for the htmljs-parser package indicating a patch release. In src/util/validators.ts, a new public enum Validity is introduced with three values: invalid, valid, and enclosed. The validation functions isValidStatement, isValidAttrValue, and isValid are updated to return Validity instead of boolean. The implementation logic is modified to track an enclosed state variable and return appropriate Validity values based on validation outcomes, replacing previous boolean returns.

🚥 Pre-merge checks | ✅ 1 | ❌ 2

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.
Description check	❓ Inconclusive	No description was provided by the author, making it impossible to assess whether the description relates to the changeset.	Add a pull request description explaining the motivation for replacing boolean returns with the Validity enum and how it improves the API.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: exposing more information about statement and attribute value validity by introducing a Validity enum.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch expose-validity-info

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/util/validators.ts (1)

83-97: ⚠️ Potential issue | 🟠 Major

Inconsistent isEnclosed handling for single LF newline.

The CRLF branch (lines 90) and the general character branch (line 94) both set isEnclosed = false when outside any group, but the single NEWLINE branch (lines 83-85) does not. This means a single LF character outside grouping constructs won't mark the expression as non-enclosed, while CRLF would.

If intentional, consider adding a comment explaining why. Otherwise:

🐛 Proposed fix for consistency

     if (code === CODE.NEWLINE) {
+      if (isEnclosed && !expr.groupStack.length) isEnclosed = false;
       parser.forward = 1;
       parser.activeState.eol.call(parser, 1, parser.activeRange);
     } else if (

[codecov]

Codecov Report

❌ Patch coverage is 92.30769% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 91.87%. Comparing base (e4df379) to head (a11c1f1).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/util/validators.ts	92.30%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #209      +/-   ##
==========================================
- Coverage   91.88%   91.87%   -0.02%     
==========================================
  Files          28       28              
  Lines        1418     1427       +9     
  Branches      319      323       +4     
==========================================
+ Hits         1303     1311       +8     
- Misses         53       54       +1     
  Partials       62       62              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/util/validators.ts (1)

31-48: ⚠️ Potential issue | 🟠 Major

Breaking API change: boolean → enum return type.

Line 31–48 changes public return types to Validity (numeric). Any consumer doing strict boolean checks (=== true/false) or relying on boolean typing will break. If you intend a patch release, consider keeping backward-compatible boolean wrappers (or preserving old signatures) and add new “getValidity” APIs; otherwise, bump major and document the breaking change.

🧹 Nitpick comments (1)

src/__tests__/validate.test.ts (1)

7-78: Prefer Validity.* over magic numbers in tests.

Hard-coded 0/1/2 is brittle if enum order changes and is harder to read. Import and use Validity.invalid|valid|enclosed for clarity.

Proposed refactor

-import { isValidAttrValue, isValidStatement } from "..";
+import { isValidAttrValue, isValidStatement, Validity } from "..";

-      assert.equal(isValidStatement("foo + bar"), 2);
+      assert.equal(isValidStatement("foo + bar"), Validity.enclosed);

-      assert.equal(isValidStatement("foo\n  + bar"), 1);
+      assert.equal(isValidStatement("foo\n  + bar"), Validity.valid);

-      assert.equal(isValidStatement("foo\nbar"), 0);
+      assert.equal(isValidStatement("foo\nbar"), Validity.invalid);

-      assert.equal(isValidStatement("foo ?\n  bar : baz"), 2);
+      assert.equal(isValidStatement("foo ?\n  bar : baz"), Validity.enclosed);

-      assert.equal(isValidStatement("(foo"), 0);
+      assert.equal(isValidStatement("(foo"), Validity.invalid);

-      assert.equal(isValidStatement(")"), 0);
+      assert.equal(isValidStatement(")"), Validity.invalid);

-      assert.equal(isValidAttrValue("foo + bar", false), 2);
+      assert.equal(isValidAttrValue("foo + bar", false), Validity.enclosed);

-      assert.equal(isValidAttrValue("foo=>bar", false), 2);
+      assert.equal(isValidAttrValue("foo=>bar", false), Validity.enclosed);

-      assert.equal(isValidAttrValue("foo >", false), 0);
+      assert.equal(isValidAttrValue("foo >", false), Validity.invalid);

-      assert.equal(isValidAttrValue("foo > bar", true), 2);
+      assert.equal(isValidAttrValue("foo > bar", true), Validity.enclosed);

-      assert.equal(isValidAttrValue("foo, bar", false), 0);
+      assert.equal(isValidAttrValue("foo, bar", false), Validity.invalid);

-      assert.equal(isValidAttrValue("foo;", false), 2);
+      assert.equal(isValidAttrValue("foo;", false), Validity.enclosed);

-      assert.equal(isValidAttrValue("foo;", true), 0);
+      assert.equal(isValidAttrValue("foo;", true), Validity.invalid);

-      assert.equal(isValidAttrValue("foo --", false), 2);
+      assert.equal(isValidAttrValue("foo --", false), Validity.enclosed);

-      assert.equal(isValidAttrValue("foo --", true), 0);
+      assert.equal(isValidAttrValue("foo --", true), Validity.invalid);

-      assert.equal(isValidAttrValue("foo bar", false), 0);
+      assert.equal(isValidAttrValue("foo bar", false), Validity.invalid);

-      assert.equal(isValidAttrValue("a &&\nb", true), 1);
+      assert.equal(isValidAttrValue("a &&\nb", true), Validity.valid);

-      assert.equal(isValidAttrValue("a && (\nb\n)", true), 2);
+      assert.equal(isValidAttrValue("a && (\nb\n)", true), Validity.enclosed);