fix(rss): add timestamp to guid

[avivkeller]

Description

This PR appends a publishing timestamp to each RSS entry GUID.

My only concern is if this will trigger every RSS feeder to display these articles again on merge.

I can set it to only apply to future articles by checking the date?

Validation

<item>
  <title>
    <![CDATA[ Node.js Test CI Security Incident ]]>
  </title>
  <link>https://nodejs.org/en/blog/vulnerability/march-2025-ci-incident</link>
  <guid>/blog/vulnerability/march-2025-ci-incident?1743438600617</guid>
  <pubDate>Mon, 31 Mar 2025 16:30:00 GMT</pubDate>
</item>
<item>

Related Issues

Fixes #5996

Check List

• I have read the Contributing Guidelines and made commit messages that follow the guideline.
• I have run npm run format to ensure the code follows the style guide.
• I have run npm run test to check if all tests are passing.
• I have run npx turbo build to check if the website builds without errors.
• I've covered new added functionality with unit tests if necessary.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
nodejs-org	✅ Ready (Inspect)	Visit Preview	Apr 15, 2025 2:33pm

[Copilot]

Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (1)

apps/site/next-data/generators/websiteFeeds.mjs:44

• Appending a timestamp to the GUID may cause RSS readers to treat all posts as new on every update. Confirm that this behavior is intentional or consider documenting the expected behavior to avoid unintended feed refreshes.

guid: `${post.slug}?${date.getTime()}`,

[avivkeller]

Example: https://nodejs-org-git-rss-guid-timestamp-openjs.vercel.app/en/feed/vulnerability.xml

[AugustinMauroy]

LGTM !

[MattIPv4]

Can I ask why we're doing this -- what does it achieve that the existing guids + pubDates don't?

And yes, given they're essentially new guids I suspect there's a good chance some readers will see them as new if the readers aren't looking at pubDate.

[avivkeller]

Can I ask why we're doing this -- what does it achieve that the existing guids + pubDates don't?

According to #5996, pubDate isn't enough for RSS feeders to indicate that an article changed, as many feeders only show an update if the GUID changes. This change makes it so the guid changes when an article is updated.

[MattIPv4]

Ah okay, that makes sense, and I think that also answers your question about whether this is going to make readers see them as new articles -- if the intent of the change is to make the timestamp changing trigger readers to see them as new articles, by that same logic adding the timestamp in the first place will make them see them as new articles.

[bmuenzenmeyer]

I can set it to only apply to future articles by checking the date?

this was going to be my suggestion too

[thehale]

I can set it to only apply to future articles by checking the date?

Wouldn't it also need to apply to future updates to existing articles?

It's probably the same implementation code (only concatenate the timestamp into the guid if the timestamp is greater than a fixed switchover date), but I want to make sure the scenario is considered.

---

Also, the RSS reader I use (tt-rss) would treat each guid update as a new article. (related blog post: https://theorangeone.net/posts/rss-guids/)

[bmuenzenmeyer]

Wouldn't it also need to apply to future updates to existing articles?

ideally yes, though if that's hard to code i'd still take this is under consideration work as an improvement.

[avivkeller]

No, it's not hard to code. The pubDate represents the latest edit, despite it not not having any effect on RSS displaying updates

[avivkeller]

Okay, I have it set to only enforce on pubDate > 1744761600000 (April 16th, 2025). I'll change this to the day of merge, but this is a starting point.

You can ensure that this date is configured correctly by seeing that, on any XML, no ?<time> exist on the GUIDs, however, the test case w/ the ?<time> GUID passes.

[bjohansebas]

LGTM

[github-actions]

Lighthouse Results

URL	Performance	Accessibility	Best Practices	SEO	Report
/en	🔴 71	🟢 100	🟢 100	🟢 91	🔗
/en/about	🟢 100	🟢 100	🟢 100	🟢 91	🔗
/en/about/previous-releases	🟢 99	🟢 100	🟢 100	🟢 92	🔗
/en/download	🟢 97	🟢 100	🟢 100	🟢 91	🔗
/en/blog	🟢 99	🟢 100	🟢 96	🟢 92	🔗

[github-actions]

Unit Test Coverage Report

Title	Lines	Statements	Branches	Functions
@node-core/ui-components		95.83% (161/168)	77.86% (102/131)	88.57% (31/35)
@nodejs/website		84.78% (496/585)	75.79% (166/219)	86.88% (106/122)

Title	Tests	Skipped	Failures	Errors	Time
@node-core/ui-components	24	0 💤	0 ❌	0 🔥	4.859s ⏱️
@nodejs/website	156	0 💤	0 ❌	0 🔥	6.296s ⏱️