Fix build failures from module format mismatch, missing workflow trigger, and local testing issues

[Copilot]

Summary

This PR fixes three issues preventing builds from working on the production branch, as reported in the issue.

Problem 1: CommonJS/ES Module Mismatch ✅ FIXED

Root Cause: The package.json had "type": "commonjs" but all TypeScript/JavaScript files used ES module syntax (import/export). This caused Next.js build failures with errors like:

Specified module format (CommonJs) is not matching the module format of the source code (EcmaScript Modules)

Solution:

• ✅ Changed package.json type from "commonjs" to "module" to match the actual code syntax
• ✅ Updated generate-version.ts to use proper ES module syntax (import statements, fileURLToPath)
• ✅ Updated setup-labels.ts to use ES module import syntax
• ✅ Updated npm scripts (predev/prebuild) to use tsx instead of node for running TypeScript files

Problem 2: Builds Not Triggered Automatically by Bot ✅ FIXED

Root Cause: When the Release workflow merges dev into prod and pushes using GITHUB_TOKEN, it doesn't trigger other workflows due to GitHub's security feature that prevents infinite loops.

Solution:

• ✅ Added repository_dispatch trigger to nextjs.yml (event type: deploy-to-pages)
• ✅ Updated create-release.ts to send repository_dispatch event after pushing to prod
• ✅ Checkout prod branch explicitly when triggered via repository_dispatch
• ✅ Proper error handling with token validation and actionable error messages
• ✅ Graceful fallback with manual trigger instructions if dispatch fails

How it works:

1. User merges Changeset PR (ci(repo): version packages #97) into dev
2. Release workflow runs, merges dev → prod, and pushes
3. create-release.ts sends repository_dispatch event (deploy-to-pages)
4. Deploy workflow triggers via repository_dispatch and deploys to GitHub Pages

Problem 3: Local Testing with Production Build ✅ FIXED

Root Cause: Production builds include /geo-invaders base path for GitHub Pages, causing 404 errors when served locally.

Solution:

• ✅ Added build:local script that builds without the GitHub Pages base path
• ✅ Removed NODE_ENV override to prevent Next.js warnings about non-standard values
• ✅ Updated next.config.mjs with clearer comments about build modes
• ✅ Updated README with clear instructions for local testing vs production builds
• ✅ Added -s flag to serve for SPA mode

How it works:

• npm run build sets NODE_ENV=production → builds with /geo-invaders base path
• npm run build:local leaves NODE_ENV unset → builds without base path for local testing
• Both create production-optimized builds, only the base path differs

Files Changed

• ✅ .github/workflows/nextjs.yml: Changed to repository_dispatch trigger, simplified checkout logic
• ✅ .github/scripts/create-release.ts: Added repository_dispatch event with proper error handling
• ✅ package.json: Changed type to "module", updated scripts to use tsx, added build:local script (without NODE_ENV override)
• ✅ next.config.mjs: Improved comments and variable naming for clarity
• ✅ scripts/generate-version.ts: Converted to ES module syntax
• ✅ scripts/setup-labels.ts: Converted to ES module syntax
• ✅ README.md: Updated build & deploy documentation with local testing instructions

Verification

• ✅ Code review completed - all feedback addressed
• ✅ CodeQL security scan passed - 0 alerts
• ✅ YAML syntax validated
• ✅ Linting passes
• ✅ Error handling improved with token validation
• ✅ Version generation script works correctly
• ✅ Local testing workflow documented
• ✅ No PAT required - uses GITHUB_TOKEN with repository_dispatch
• ✅ No Next.js warnings about non-standard NODE_ENV values

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Builds aren't working on the production branch</issue_title>
<issue_description>There are many errors causing it for the the builds, to not be deployed on GitHub Pages.

Since I changed the branches (renaming main to dev, and a new branch named prod for Github Pages), I needed to change how workflows work and everything.

But... since this change:

• Builds, are not triggered automatically on commit by the GitHub actions bot. This maybe because of the bot permissions, but we will see.
• Builds fail because of a CommonJS problem that NextJS reports. (This file is being treated as an ES module because it has a '.js' file extension and '/home/runner/work/geo-invaders/geo-invaders/package.json' contains "type": "module". To treat it as a CommonJS script, rename it to use the '.cjs' file extension.)

While I investigate this issue, the app won't have the latest updates.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Builds aren't working on the production branch #105

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[changeset-bot]

⚠️ No Changeset found

Latest commit: e795bbc

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes changesets to release 1 package

Name	Type
geo-invaders	Patch

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[mergify]

🧪 CI Insights

Here's what we observed from your CI run for e795bbc.

🟢 All jobs passed!

But CI Insights is watching 👀

[notthebestdev]

@copilot I tested everything, it works perfectly! Except.. there's a single problem..

I built the project, with npm run build

But, then when I run the npm run start command, and when we go to our local development URL, the assets can't load on static builds, why?

 HTTP  2/2/2026 6:22:51 PM 127.0.0.1 Returned 404 in 3 ms
 HTTP  2/2/2026 6:22:51 PM 127.0.0.1 Returned 404 in 2 ms
 HTTP  2/2/2026 6:22:51 PM 127.0.0.1 Returned 404 in 2 ms
 HTTP  2/2/2026 6:22:51 PM 127.0.0.1 Returned 404 in 1 ms
 HTTP  2/2/2026 6:22:51 PM 127.0.0.1 Returned 404 in 2 ms
 HTTP  2/2/2026 6:22:51 PM 127.0.0.1 Returned 404 in 2 ms

Can you please fix it?

[Copilot]

@copilot I tested everything, it works perfectly! Except.. there's a single problem..

I built the project, with npm run build
...

Fixed in commit 0f52356!

The 404 errors occur because npm run build creates a production build with the /geo-invaders base path (for GitHub Pages), but npm run start serves from / locally.

Solution: Use the new build:local script for local testing:

npm run build:local  # Builds without base path
npm run start        # Serves at http://localhost:3000 ✓

For production deployment, continue using npm run build (the GitHub Actions workflow handles deployment automatically).

Updated the README with detailed instructions in the "Build & Deploy" section.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• fonts.googleapis.com
  • Triggering command: /usr/local/bin/node node /home/REDACTED/work/geo-invaders/geo-invaders/node_modules/.bin/next build (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[notthebestdev]

@copilot This is overall good now, but there's is still a problem; see in the code you did, you basically put to run the Release on the dev branch, but I don't quite understand what you did to the workflow files.

What I want to do, is after the automatic Changeset PR, merged when I want by me (find example @ #97 ), well it creates a release and a tag, and merges the dev branch into the prod, to then trigger the workflow to deploy the app to GitHub Pages.

Now, this is what I wanted, but the workflow doesn't run when committing. I don't know to do it, still a GitHub Personal Token could do it.

But, please try to make a fix without a GitHub PAT, and I will merge this PR (if you can fix it, of course).

P.S. I've upgraded your firewall rules normally to allow builds.

[Copilot]

@copilot This is overall good now, but there's is still a problem; see in the code you did, you basically put to run the Release on the dev branch, but I don't quite understand what you did to the wor...

Fixed in commits 1071ac0 and 33a51eb!

The issue was that workflow_run doesn't work reliably when triggered by GITHUB_TOKEN pushes. I've replaced it with repository_dispatch, which is the recommended approach for this scenario.

How it works now:

1. You merge the Changeset PR (ci(repo): version packages #97) into dev
2. Release workflow runs and merges dev → prod
3. create-release.ts sends a repository_dispatch event (type: deploy-to-pages)
4. Deploy workflow triggers automatically via the dispatch event
5. App deploys to GitHub Pages

No PAT required - this uses GITHUB_TOKEN with the repository_dispatch event, which bypasses the workflow trigger limitation while maintaining security.

The script includes proper error handling and will show a message if the trigger fails, with instructions to manually run the workflow from the Actions tab as a fallback.

[notthebestdev]

@copilot When i do npm run build:local, it gives me this:

❯ npm run build:local

> geo-invaders@0.4.0 prebuild:local
> NODE_ENV=development npx tsx scripts/generate-version.ts

✓ Generated version info: v0.4.0 (development)

> geo-invaders@0.4.0 build:local
> NODE_ENV=development next build

⚠ You are using a non-standard "NODE_ENV" value in your environment. This creates inconsistencies in the project and is strongly advised against. Read more: https://nextjs.org/docs/messages/non-standard-node-env
▲ Next.js 16.1.5 (Turbopack)
- Environments: .env

  Creating an optimized production build ...
✓ Compiled successfully in 1804.1ms
✓ Finished TypeScript in 1576.0ms    
✓ Collecting page data using 7 workers in 286.5ms    
Each child in a list should have a unique "key" prop.

Check the top-level render call using <__next_viewport_boundary__>. See https://react.dev/link/warning-keys for more information.
Each child in a list should have a unique "key" prop.

Check the top-level render call using <M>. See https://react.dev/link/warning-keys for more information.
Each child in a list should have a unique "key" prop.

Check the top-level render call using <meta>. See https://react.dev/link/warning-keys for more information.
Each child in a list should have a unique "key" prop.

Check the top-level render call using <head>. See https://react.dev/link/warning-keys for more information.
Each child in a list should have a unique "key" prop.

Check the top-level render call using <meta>. See https://react.dev/link/warning-keys for more information.
Each child in a list should have a unique "key" prop.

Check the top-level render call using <html>. See https://react.dev/link/warning-keys for more information.
Each child in a list should have a unique "key" prop.

Check the top-level render call using <meta>. See https://react.dev/link/warning-keys for more information.
Each child in a list should have a unique "key" prop.

Check the top-level render call using <head>. See https://react.dev/link/warning-keys for more information.
Each child in a list should have a unique "key" prop.

Check the top-level render call using <__next_viewport_boundary__>. See https://react.dev/link/warning-keys for more information.
Each child in a list should have a unique "key" prop.

Check the top-level render call using <html>. See https://react.dev/link/warning-keys for more information.
Each child in a list should have a unique "key" prop.

Check the top-level render call using <meta>. See https://react.dev/link/warning-keys for more information.
Each child in a list should have a unique "key" prop.

Check the top-level render call using <head>. See https://react.dev/link/warning-keys for more information.
Error occurred prerendering page "/_global-error". Read more: https://nextjs.org/docs/messages/prerender-error
TypeError: Cannot read properties of null (reading 'useContext')
    at ignore-listed frames {
  digest: '1133745677'
}
Export encountered an error on /_global-error/page: /_global-error, exiting the build.
⨯ Next.js build worker exited with code: 1 and signal: null

After your changes, please build the app locally for you and see if it works

[Copilot]

@copilot When i do npm run build:local, it gives me this:

...

Fixed in commit c884571!

The error was caused by setting NODE_ENV=development during next build. Next.js only accepts standard NODE_ENV values (production, development for dev server, or test), and using non-standard values triggers warnings and can cause build failures.

What changed:

• Removed NODE_ENV=development from build:local script
• Next.js now runs in production mode (default) but without the GitHub Pages base path
• The build is still optimized and production-ready, just served from / instead of /geo-invaders

Usage remains the same:

npm run build:local  # Builds without base path, no warnings
npm run start        # Serves at http://localhost:3000

The build should now complete successfully in your local environment without the non-standard NODE_ENV warning or the useContext error.