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

Issue: Automatic DateTime Updates (lastmod) Requires Additional Extensions for MDX Files #174

New Issue
Closed
opened 2026-10-05 02:31:15 +02:00 by adam · 7 comments
adam commented 2026-10-05 02:31:15 +02:00
Owner
Copy link
Copy source

Describe the bug
Despite "Auto-update modified date" being enabled in frontmatter.json, the lastmod field isn't updated for MDX files unless an additional extension is installed, like MDX on the marketplace.

To Reproduce
Steps to reproduce the behavior:

  1. Ensure the frontMatter.content.autoUpdateDate setting is set to true and no language support installed (or enabled) on VS Code.
  2. Use a block like this in your mdx file:
---
title: Sample Title
date: '2022-01-03T19:26:06.826Z'
lastmod: '2022-01-03T19:26:06.826Z'
---
  1. Update the content as you would in the editor.
  2. Observe that the lastmod property is not updated
    Note: The FrontMatter extension parses this block just fine, and if I explicitly click it to set the value, it does behave properly.

Expected behavior
One extension probably shouldn't depend on the presence of another to function, unless otherwise explicitly deemed necessary. I'd expect the plugin to update the lastmod value regardless of the language support being installed (this may be wrong of me to expect).

Screenshots
N/A

VS Code Version

Version: 1.63.2 (Universal)
Commit: 899d46d82c4c95423fb7e10e68eba52050e30ba3
Date: 2021-12-15T09:37:28.172Z (2 wks ago)
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Darwin arm64 21.2.0

Extension Version
v5.9.0

Additional context
isMarkdownFile in ArticleHelper (seen here) expects the language to be identified. MDX isn't supported out-of-the-box with VS Code-- meaning that for this method to work it requires installing another extension for this extension to support it.

I'm torn about whether or not this behavior makes sense-- I could understand arguments either way. If we wanted to support this without requiring the extension, we could check the file extension as one way to determine if it is a mdx file.

**Describe the bug** Despite "Auto-update modified date" being enabled in **frontmatter.json**, the `lastmod` field isn't updated for MDX files unless an additional extension is installed, like [MDX on the marketplace](https://marketplace.visualstudio.com/items?itemName=silvenon.mdx). **To Reproduce** Steps to reproduce the behavior: 1. Ensure the `frontMatter.content.autoUpdateDate` setting is set to **true** and no language support installed (or enabled) on VS Code. 2. Use a block like this in your mdx file: ```markdown --- title: Sample Title date: '2022-01-03T19:26:06.826Z' lastmod: '2022-01-03T19:26:06.826Z' --- ``` 3. Update the content as you would in the editor. 4. Observe that the lastmod property is not updated Note: The FrontMatter extension parses this block just fine, and if I explicitly click it to set the value, it does behave properly. **Expected behavior** One extension _probably_ shouldn't depend on the presence of another to function, unless otherwise explicitly deemed necessary. I'd expect the plugin to update the lastmod value regardless of the language support being installed (this may be wrong of me to expect). **Screenshots** N/A **VS Code Version** ``` Version: 1.63.2 (Universal) Commit: 899d46d82c4c95423fb7e10e68eba52050e30ba3 Date: 2021-12-15T09:37:28.172Z (2 wks ago) Electron: 13.5.2 Chromium: 91.0.4472.164 Node.js: 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin arm64 21.2.0 ``` **Extension Version** `v5.9.0` **Additional context** `isMarkdownFile` in `ArticleHelper` (seen [here](https://github.com/estruyf/vscode-front-matter/blob/main/src/helpers/ArticleHelper.ts#L114)) expects the language to be identified. MDX isn't supported out-of-the-box with VS Code-- meaning that for this method to work it requires installing another extension for this extension to support it. I'm torn about whether or not this behavior makes sense-- I could understand arguments either way. If we wanted to support this without requiring the extension, we could check the file extension as one way to determine if it is a mdx file. <!-- github-sync-id:1092782386 -->
adam closed this issue 2026-10-05 02:31:15 +02:00
adam commented 2026-10-05 02:31:16 +02:00
Author
Owner
Copy link
Copy source

Thanks @farmerau for opening this issue! This is indeed something that needs to get fixed/supported.

Thanks @farmerau for opening this issue! This is indeed something that needs to get fixed/supported. <!-- github-comment-id:1004677991 -->
adam commented 2026-10-05 02:31:17 +02:00
Author
Owner
Copy link
Copy source

@estruyf Cheers! If you'd like help on this, I'm certainly happy to open a PR.

@estruyf Cheers! If you'd like help on this, I'm certainly happy to open a PR. <!-- github-comment-id:1005167919 -->
adam commented 2026-10-05 02:31:17 +02:00
Author
Owner
Copy link
Copy source

@farmerau PRs are always welcome! Extra hands are useful to make it better, so if you have time and want to do it. I'll be happy to merge it later.

@farmerau PRs are always welcome! Extra hands are useful to make it better, so if you have time and want to do it. I'll be happy to merge it later. <!-- github-comment-id:1005177914 -->
adam commented 2026-10-05 02:31:18 +02:00
Author
Owner
Copy link
Copy source

@estruyf Sweet, I'll try to get a PR out for this today (EST).

@estruyf Sweet, I'll try to get a PR out for this today (EST). <!-- github-comment-id:1005777606 -->
adam commented 2026-10-05 02:31:19 +02:00
Author
Owner
Copy link
Copy source

@estruyf In further digging, there are two primary ways to handle this that I can see:

  1. We make the dependency on the MDX language extension explicit in the extension manifest, via extensionDependencies.
  2. We prefer not taking on the dependency and instead reference TextDocument.fileName as a fallback in isMarkdownFile when we check to see if the file belongs to one of the supported languages.

I admittedly don't have a lot of practice with VS Code extensions, so I'm not sure what the best practice would be in this case.

My gut leans towards number 2, primarily because I anticipate MDX is the exceptional use-case and it doesn't seem fair to ask users to install an extension that they might not be using in reality.

@estruyf In further digging, there are two primary ways to handle this that I can see: 1. We make the dependency on the MDX language extension explicit in the [extension manifest](https://code.visualstudio.com/api/references/extension-manifest), via `extensionDependencies`. 2. We prefer not taking on the dependency and instead reference `TextDocument.fileName` as a fallback in `isMarkdownFile` when we check to see if the file belongs to one of the supported languages. I admittedly don't have a lot of practice with VS Code extensions, so I'm not sure what the best practice would be in this case. My gut leans towards number 2, primarily because I anticipate MDX is the exceptional use-case and it doesn't seem fair to ask users to install an extension that they might not be using in reality. <!-- github-comment-id:1005853963 -->
adam commented 2026-10-05 02:31:19 +02:00
Author
Owner
Copy link
Copy source

@farmerau it is now available in the beta version

@farmerau it is now available in the beta version <!-- github-comment-id:1005951079 -->
adam commented 2026-10-05 02:31:20 +02:00
Author
Owner
Copy link
Copy source

Released in v5.10.0

Released in `v5.10.0` <!-- github-comment-id:1008807984 -->
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#174