adam/vscode-front-matter
1
0 Fork 0
mirror of https://github.com/estruyf/vscode-front-matter.git synced 2026-10-30 23:41:57 +01:00
Code Issues 77 Packages Projects Releases Wiki Activity

Enhancement: Support metadata validation for numeric types #370

New Issue
Open
opened 2026-10-05 02:43:31 +02:00 by adam · 5 comments
adam commented 2026-10-05 02:43:31 +02:00
Owner
Copy link
Copy source

Is your feature request related to a problem? Please describe.

I've been working to define the metadata keys for a theme I'm developing in Front Matter. Today, I was defining the settings for general content pages based on the work I've done to develop JSON schemas for site configuration and metadata.

While updating the content type definition in Front Matter for the Platen.TableOfContents.MinimumLevel and Platen.TableOfContents.MaximumLevel fields, I realized that while I can require the values be numbers, I can't require that they be within a specific range. In this case, I would like to set the minimum as 1 and maximum as 6.

Describe the solution you'd like

I'd like additional keys for defining fields with a type of number:

  • minimum: The minimum value the number can be, inclusive. For a value of 3:
    • 2 is invalid
    • 3 is valid
    • 4 is valid
  • maximum: The maximum value the number can be, inclusive. For a value of 3:
    • 2 is valid
    • 3 is valid
    • 4 is invalid
  • exlusiveMinimum: The minimum value the number can be, exclusive. For a value of 3:
    • 2 is invalid
    • 3 is invalid
    • 4 is valid
  • exclusiveMaximum: The maximum value the number can be, exclusive. For a value of 3:
    • 2 is invalid
    • 3 is valid
    • 4 is valid

Describe alternatives you've considered

I'm not sure I see another way to handle metadata validation without transitioning towards a semi-unified model between metadata definitions and data-type definitions, which can take advantage of JSON Schema functionality but are more complex to write.

Additional context

Similar to the newly implemented when functionality, I think there's a lot of utility in being able to define a validation field that allows a configuration author to opt-in for more complex configuration definition to provide a better UX for end users.

For example, even with the described additional keys above, there's no way to also validate that the specified value for the MinimumLevel field on a page is less than or equal to the MaximumLevel field's value.

**Is your feature request related to a problem? Please describe.** I've been working to define the metadata keys for a theme I'm developing in Front Matter. Today, I was defining the settings for [general content pages][01] based on the work I've done to develop JSON schemas for site configuration and metadata. While updating the content type definition in Front Matter for the [`Platen.TableOfContents.MinimumLevel`][02] and [`Platen.TableOfContents.MaximumLevel`][03] fields, I realized that while I can require the values be numbers, I can't require that they be within a specific range. In this case, I would like to set the minimum as `1` and maximum as `6`. **Describe the solution you'd like** I'd like additional keys for defining fields with a `type` of `number`: - `minimum`: The minimum value the number can be, inclusive. For a value of `3`: - `2` is invalid - `3` is valid - `4` is valid - `maximum`: The maximum value the number can be, inclusive. For a value of `3`: - `2` is valid - `3` is valid - `4` is invalid - `exlusiveMinimum`: The minimum value the number can be, exclusive. For a value of `3`: - `2` is invalid - `3` is invalid - `4` is valid - `exclusiveMaximum`: The maximum value the number can be, exclusive. For a value of `3`: - `2` is invalid - `3` is valid - `4` is valid **Describe alternatives you've considered** I'm not sure I see another way to handle metadata validation without transitioning towards a semi-unified model between metadata definitions and data-type definitions, which can take advantage of JSON Schema functionality but are more complex to write. **Additional context** Similar to the newly implemented `when` functionality, I think there's a lot of utility in being able to define a `validation` field that allows a configuration author to opt-in for more complex configuration definition to provide a better UX for end users. For example, even with the described additional keys above, there's no way to also validate that the specified value for the `MinimumLevel` field on a page is less than or equal to the `MaximumLevel` field's value. [01]: https://platen.io/schemas/platen/content/page/ [02]: https://platen.io/schemas/platen/content/page/#tableofcontents.minimumlevel [03]: https://platen.io/schemas/platen/content/page/#tableofcontents.maximumlevel <!-- github-sync-id:1460040651 -->
adam commented 2026-10-05 02:43:32 +02:00
Author
Owner
Copy link
Copy source

Can't we just use an underlying script for this kind of checks?

FrontMatter do support custom scripts.

Can't we just use an underlying script for this kind of checks? FrontMatter do support custom scripts. <!-- github-comment-id:1335078414 -->
adam commented 2026-10-05 02:43:33 +02:00
Author
Owner
Copy link
Copy source

@dennisl68-castra first, there is a need for a simple way to validate metadata/fields to define when they are allowed to appear and when not. Once that is implemented, we can start thinking about custom scripts.

@michaeltlombardi, these extra operators make sense.

@dennisl68-castra first, there is a need for a simple way to validate metadata/fields to define when they are allowed to appear and when not. Once that is implemented, we can start thinking about custom scripts. @michaeltlombardi, these extra operators make sense. <!-- github-comment-id:1335258082 -->
adam commented 2026-10-05 02:43:33 +02:00
Author
Owner
Copy link
Copy source

@michaeltlombardi was working on the documentation and started to think about this. We already have this implemented with: gt, gte, lt, and lte.

@michaeltlombardi was working on the documentation and started to think about this. We already have this implemented with: `gt`, `gte`, `lt`, and `lte`. <!-- github-comment-id:1342924729 -->
adam commented 2026-10-05 02:43:34 +02:00
Author
Owner
Copy link
Copy source

@estruyf just did a quick peek at the docs, maybe I'm missing something - where are those documented? Is that for the new where functionality?

@estruyf just did a quick peek at the docs, maybe I'm missing something - where are those documented? Is that for the new `where` functionality? <!-- github-comment-id:1343336255 -->
adam commented 2026-10-05 02:43:35 +02:00
Author
Owner
Copy link
Copy source

@michaeltlombardi it might have been me. Think I confused it with the conditional UI functionality and its operators 🫣

@michaeltlombardi it might have been me. Think I confused it with the conditional UI functionality and its operators 🫣 <!-- github-comment-id:1344066162 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/vscode-front-matter#370