adam/vscode-front-matter
1
0 Fork 0
mirror of https://github.com/estruyf/vscode-front-matter.git synced 2026-11-03 09:02:19 +01:00
Code Issues 77 Packages Projects Releases Wiki Activity

Enhancement: Add alternative method for content type identification #372

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

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

Currently, the only way to have Front Matter recognize a file as a particular content type is to define the type field in the file's frontmatter and have that value map to a known content type.

For some static site generators, like Hugo, the type field carries semantic meaning outside of Front Matter. This can (but doesn't always) cause conflicts or require work arounds for defining content types in Front Matter.

Describe the solution you'd like

I would like an alternative way to inform Front Matter about settings/behaviors specific to Front Matter, rather than the content/static site generator.

For example, adding the _frontMatter (or other name, this is just an example) field as a map of key-value pairs (type being one of them) and overriding other discoverable values with those would allow Front Matter to be used side-by-side with static site generators that have colliding field names.

If the _frontMatter field is an optional override, it won't require any additional changes from users who don't have to resolve the conflict.

Describe alternatives you've considered

Right now, the only alternative is to ensure my content types always match my Hugo types and try to account for the complexities of differing needs with the newly implemented #362 and conditional UI.

Additional context

If the _frontMatter field is implemented, the UI can be updated to have a foldable section in the side bar for altering settings specific to that file and Front Matter, if needed (though I think that's a separate feature request if this is implemented). This also opens the possibility of extending/overriding (a limited subset of) behaviors on a per-file basis. For example, defining an alternate preview path or metadata requirements. Again, I don't mean to bikeshed on that idea here, simply to remark that implementing this feature to resolve a field name collision opens the possibility for investigation and discussion.

**Is your feature request related to a problem? Please describe.** Currently, the only way to have Front Matter recognize a file as a particular content type is to define the `type` field in the file's frontmatter and have that value map to a known content type. For some static site generators, [like Hugo](https://gohugo.io/content-management/types/), the `type` field carries semantic meaning outside of Front Matter. This _can_ (but doesn't always) cause conflicts or require work arounds for defining content types in Front Matter. **Describe the solution you'd like** I would like an alternative way to inform Front Matter about settings/behaviors _specific to Front Matter_, rather than the content/static site generator. For example, adding the `_frontMatter` (or other name, this is just an example) field as a map of key-value pairs (`type` being one of them) and overriding other discoverable values with those would allow Front Matter to be used side-by-side with static site generators that have colliding field names. If the `_frontMatter` field is an optional override, it won't require any additional changes from users who don't have to resolve the conflict. **Describe alternatives you've considered** Right now, the only alternative is to ensure my content types always match my Hugo types and try to account for the complexities of differing needs with the newly implemented #362 and conditional UI. **Additional context** If the `_frontMatter` field is implemented, the UI can be updated to have a foldable section in the side bar for altering settings specific to that file and Front Matter, if needed (though I think that's a _separate_ feature request if this is implemented). This also opens the possibility of extending/overriding (a limited subset of) behaviors on a per-file basis. For example, defining an alternate preview path or metadata requirements. Again, I don't mean to bikeshed on that idea here, simply to remark that implementing this feature to resolve a field name collision opens the possibility for investigation and discussion. <!-- github-sync-id:1463789143 -->
adam closed this issue 2026-10-05 02:43:39 +02:00
adam commented 2026-10-05 02:43:40 +02:00
Author
Owner
Copy link
Copy source

So what about supporting a field for what it actually is?

ContentType

So what about supporting a field for what it actually is? `ContentType` <!-- github-comment-id:1335076516 -->
adam commented 2026-10-05 02:43:41 +02:00
Author
Owner
Copy link
Copy source

For this, we also need to think about how to remap older articles that already have the type defined, but contenttype can make sense.

For this, we also need to think about how to remap older articles that already have the `type` defined, but `contenttype` can make sense. <!-- github-comment-id:1335254255 -->
adam commented 2026-10-05 02:43:41 +02:00
Author
Owner
Copy link
Copy source

I think adding a limited set of convenient top-level keys is a good idea for ease-of-use (like contentType), but if this usage starts to expand it'll be best to keep it in a map of settings specific to Front Matter to avoid conflicts with other tooling.

I'd suggest that we add contentType and frontMatter.contentType with the following override logic:

# Old specifier
type: foo
# new convenience key
contentType: bar
# explicit setting
frontMatter:
  contentType: baz
  1. If frontMatter.contentType is defined, don't check other keys to determine content type.
  2. If frontMatter.contentType isn't defined, check contentType to see if there's a matching content type defined. If there is, use that.
  3. If frontMatter.contentType isn't defined and contentType is undefined or doesn't resolve to a matching content type, check type. If type matches an existing content type, use that.
  4. If frontMatter.contentType isn't defined and neither type nor contentType resolved to a defined content type, use the default content type.

That should be backwards compatible. Thinking more about the top-level keys, my main concern is that there's always a potential for conflict, especially if they don't have a prefix and use terms that are relatively common (like type, contentType, etc) because they're semantically useful.

I think adding a _limited_ set of convenient top-level keys is a good idea for ease-of-use (like `contentType`), but if this usage starts to expand it'll be best to keep it in a map of settings specific to Front Matter to avoid conflicts with other tooling. I'd suggest that we add `contentType` and `frontMatter.contentType` with the following override logic: ```yaml # Old specifier type: foo # new convenience key contentType: bar # explicit setting frontMatter: contentType: baz ``` 1. If `frontMatter.contentType` is defined, don't check other keys to determine content type. 2. If `frontMatter.contentType` isn't defined, check `contentType` to see if there's a matching content type defined. If there is, use that. 3. If `frontMatter.contentType` isn't defined and `contentType` is undefined or doesn't resolve to a matching content type, check `type`. If `type` matches an existing content type, use that. 4. If `frontMatter.contentType` isn't defined and neither `type` nor `contentType` resolved to a defined content type, use the default content type. That should be backwards compatible. Thinking more about the top-level keys, my main concern is that there's always a potential for conflict, especially if they don't have a prefix and use terms that are relatively common (like `type`, `contentType`, etc) because they're semantically useful. <!-- github-comment-id:1335412331 -->
adam commented 2026-10-05 02:43:42 +02:00
Author
Owner
Copy link
Copy source

For the next release, I'll add support for a new field called fmContentType. As @michaeltlombardi highlighted, using type or contentType might create other conflicts. By prefixing it with fm, it would be less common that people would use it.

Also, think about a global setting to define the content type field.

Logic would be changed to:

  • Get the fmContentType from the article
  • If not present, it will check the type field
  • If not present, it will use the default content type
For the next release, I'll add support for a new field called `fmContentType`. As @michaeltlombardi highlighted, using `type` or `contentType` might create other conflicts. By prefixing it with `fm`, it would be less common that people would use it. Also, think about a global setting to define the content type field. Logic would be changed to: - Get the `fmContentType` from the article - If not present, it will check the `type` field - If not present, it will use the default content type <!-- github-comment-id:2217146632 -->
adam commented 2026-10-05 02:43:43 +02:00
Author
Owner
Copy link
Copy source

Released in version v10.3.0.

Released in version v10.3.0. <!-- github-comment-id:2286577986 -->
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#372