Enable exports

[Jennings Anderson (jenningsanderson)]

1. Add functionality to link to OSM version specifically
2. Package up the explore-site so the QA console can use the components

[github-actions]

🗺️ Overture Maps Explorer preview is live!

🌍 Preview	https://staging.overturemaps.org/explore-site/pr/265/index.html
🕐 Updated	2026-03-30T14:25:09Z
📝 Commit	717088f

Note

♻️ This preview updates automatically with each push to this PR.

[Alex Iannicelli (atiannicelli)]

Cool

[Brandon Liu (bdon)]

There is an issue with staging deploys such as https://staging.overturemaps.org/explore-site/pr/265/index.html

• assets in the public folder do not have their URLs rewritten by next.js when the site is deployed to a subpath (staging.overturemaps.org/explore-site/pr/265) instead of the root (explore.overturemaps.org)

This means that fonts and icons don't load and you see 403 errors in the console.

[Jennings Anderson (jenningsanderson)]

There is an issue with staging deploys such as https://staging.overturemaps.org/explore-site/pr/265/index.html

• assets in the public folder do not have their URLs rewritten by next.js when the site is deployed to a subpath (staging.overturemaps.org/explore-site/pr/265) instead of the root (explore.overturemaps.org)

This means that fonts and icons don't load and you see 403 errors in the console.

Should we just throw fonts, icons and other known shared assets into the gh-pages/ directory to avoid these types of errors more generally?

[github-actions]

❌ PR Title Validation Failed

Error: No release type found in pull request title "Enable exports". Add a prefix to indicate what kind of release this pull request corresponds to. For reference, see https://www.conventionalcommits.org/

Available types:

• BUG
• FEATURE
• ENHANCEMENT
• DOCS
• REFACTOR
• TEST
• CHORE
• PERFORMANCE
• SECURITY
• INVESTIGATION

---

Examples:

• [BUG] Fix null pointer exception in geometry validator
• [REFACTOR](schema) Consolidate validation logic

See the Overture Maps Foundation GitHub usage guidelines for full documentation.

[John McCall (lowlydba)]

There is an issue with staging deploys such as https://staging.overturemaps.org/explore-site/pr/265/index.html

• assets in the public folder do not have their URLs rewritten by next.js when the site is deployed to a subpath (staging.overturemaps.org/explore-site/pr/265) instead of the root (explore.overturemaps.org)

This means that fonts and icons don't load and you see 403 errors in the console.

Should we just throw fonts, icons and other known shared assets into the gh-pages/ directory to avoid these types of errors more generally?

Jennings Anderson (@jenningsanderson) I updated the branch from main and this should be fixed now for the existing fonts/icons/etc. on the preview/branch deployments (#283)

[Copilot]

Pull request overview

This PR aims to make the explore-site package consumable by external clients (e.g., the QA console) via package.json exports, and improves OpenStreetMap source linking by supporting links to a specific OSM element version.

Changes:

• Added an exports map in package.json to expose app entrypoint, components, selected libs, and global CSS.
• Updated OSM source parsing/link generation to support n|w|r<id>@<version> and link directly to the version’s history page.

Reviewed changes

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

File	Description
package.json	Introduces subpath exports to enable importing components/libs/CSS from other packages.
components/inspector_panel/SourcesRow.jsx	Enhances OSM link generation to support record IDs containing an explicit version.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The exported components rely heavily on the Next/jsconfig path alias @/… (e.g., import … from "@/components/..."). When this package is consumed from another repo (as the PR description suggests), those imports will typically resolve against the consumer app’s @ alias (or not resolve at all), causing build/runtime failures. To make these exports usable as a library, switch internal imports to relative paths (or to this package’s own subpath exports like explore-site/components/...) or add a build step that rewrites/compiles these imports for distribution.

[Copilot]

The exports map points directly at source .jsx files that import global .css files. Many bundlers/Node environments can’t execute .jsx from dependencies without a compile step, and Next.js commonly errors on global CSS imports from node_modules. If the goal is to consume these components from another app, consider publishing compiled JS (e.g., dist/ with .js/.mjs) and converting component styles to CSS Modules (or otherwise documenting/handling required consumer configuration like transpilePackages + CSS handling).

Suggested change

	"exports": {
	".": "./app/page.jsx",
	"./components/*": "./components/*.jsx",
	"./components/nav/*": "./components/nav/*.jsx",
	"./components/inspector_panel/*": "./components/inspector_panel/*.jsx",
	"./components/map": "./components/map/index.js",
	"./components/map/*": "./components/map/*",
	"./lib/*": "./lib/*.js",
	"./lib/util/*": "./lib/util/*.js",
	"./app/globals.css": "./app/globals.css"
	},