feat: format object properties with types

[vankop]

This PR contains a:

• bugfix
• new feature
• code refactor
• test update
• typo fix
• metadata update

Motivation / Use-Case

#42
2nd proposal

Breaking Changes

no

Additional Info

Looks like for array and object we can skip formatting type.

[codecov]

Codecov Report

❌ Patch coverage is 97.67442% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 98.13%. Comparing base (62fb107) to head (db7e4f6).
⚠️ Report is 128 commits behind head on main.

Files with missing lines	Patch %	Lines
src/ValidationError.js	97.33%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #59      +/-   ##
==========================================
- Coverage   98.72%   98.13%   -0.59%     
==========================================
  Files           5        5              
  Lines         550      645      +95     
  Branches      250      268      +18     
==========================================
+ Hits          543      633      +90     
- Misses          7       12       +5     

☔ View full report in Codecov by Harness.
📢 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.

[alexander-akait]

Let's add test for multiple types, output should be like <key>: string | integer.

For objects we don't expand them, right?

[vankop]

Yes objects and arrays are not expanded

[vankop]

Multiple types could be only with anyOf | oneOf. Here we just look on type if it exists

[vankop]

so @evilebottnawi what we need in this PR still? Tests on additionalProperties ?

[alexander-akait]

@vankop all is good, i will review deeply this in near future

[alexander-akait]

/cc @vankop need rebase, also i think we should improve output using \n (like prettier do with objects 😄 ), because some error is very long

[vankop]

also i think we should improve output using \n

@evilebottnawi you have any ideas how to do it better?

When I did this I was thinking about it, but did not realized how to do it better, since it depends totally on terminal window size + font type/size. Approach when we rely only on amount of properties also fails because of glyph sizes

[alexander-akait]

@vankop the good question, maybe we can solve this in other PR, i think packages like table have algorithm for this, need look on them logic

[vankop]

/cc @evilebottnawi

Ready to review

maybe we can solve this in other PR, i think packages like table have algorithm for this, need look on them logic

I think this really important, I will take a look in table package, thanks for suggestion

[vankop]

Also interesting question is - do we need sort properties alphabetically?

[alexander-akait]

@vankop it is very old 😄 what we will do with it? close or rebase? 😄

[vankop]

I could merge main to make this relevant again

[alexander-akait]

@vankop Yeah, let's do it

[alexander-akait]

Thank you for this @vankop, and sorry it sat for so long.

The feature landed in #224, which took the same approach you proposed here — the type next to the property name, arrays and objects skipped, exactly as you described in this thread. It formats the type through formatInnerSchema rather than reading schema.properties[x].type directly, so a union renders as one type instead of foo: string,number and a property described by anyOf/$ref is covered too, and it drops the types once the shape no longer fits on a line.

The two questions you raised here are still open and are not answered by that PR: breaking a long object over several lines (also in #42 (comment)), and whether to sort properties alphabetically. Worth their own issue rather than keeping this one open on top of a 2019 base.

Closing as superseded — the idea was yours, and #225 credits you for the part of #68 it carries over.

---

Generated by Claude Code