Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

start-plugin-core: sitemap lastmod and pages.json lastBuilt are stamped with the build's wall clock (no SOURCE_DATE_EPOCH support)

Open Beginner friendly
  • Is something wrong?
#8,512 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
84/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
build-system

Research direction

Start in src/build-sitemap.ts and trace the two places where new Date() is written to sitemap.xml and pages.json. Run the minimal build reproducer with SOURCE_DATE_EPOCH set, then verify that repeated builds produce byte-identical sitemap.xml and pages.json while builds without the variable retain current behavior.

Written by the indexing model from the issue text.

Description

Which project does this relate to?

Start

Describe the bug

@tanstack/start-plugin-core's sitemap builder (src/build-sitemap.ts) writes new Date() into two places on every build:

  • <lastmod> of every sitemap entry whose route declares no sitemap.lastmod — which is every page discovered by crawlLinks, since crawled pages have no per-page config to set one on;
  • lastBuilt in pages.json.

So building the same sources twice on different days yields different output. That breaks any deploy pipeline that hashes the client dist to decide whether prod is current (ours: a Bazel build whose dist hash is compared against the last deploy; a lint-tool dependency bump re-ran the vite action and every page's lastmod moved to that day, reporting the site as changed when nothing user-visible had). It also makes the sitemap's lastmod meaningless to crawlers: Google documents that it uses lastmod only when it is "consistently and verifiably accurate", and a build date tells them every page changed on every rebuild.

There is no configuration escape hatch: the top-level sitemap options are enabled, host, outputPath only, and the default cannot be reached for crawled pages.

The reproducible-builds convention for exactly this is the SOURCE_DATE_EPOCH environment variable (https://reproducible-builds.org/specs/source-date-epoch/), which build tools consult in place of "now" for embedded timestamps. The plugin does not read it.

Complete minimal reproducer

Any Start app with prerendering, link crawling and sitemap.host set (the SEO guide's example config):

pnpm build && cp dist/client/sitemap.xml /tmp/a.xml
# next day, or with a faked clock:
faketime '+1d' pnpm build && cp dist/client/sitemap.xml /tmp/b.xml
diff /tmp/a.xml /tmp/b.xml   # every <lastmod> differs; sources unchanged

Expected: with SOURCE_DATE_EPOCH=1700000000 exported, both builds produce byte-identical sitemap.xml and pages.json. Without it, current behavior is fine to keep.

PR to follow.

Dominant language
TypeScript
Stars
15.1k
Forks
1.9k
Avg merge
2d 1h
Merged PRs (30d)
137

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from TanStack/router

All issues in TanStack/router

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.