Update CHANGELOG.md for 9.3.1 (#824)

Author: justin808

.claude/commands/update-changelog.md

@@ -109,50 +109,58 @@ When a new version is released:
 
 ### For Regular Changelog Updates
 
-1. **Determine the correct version tag to compare against**:
+1. **ALWAYS fetch latest changes first**:
+   - **CRITICAL**: Run `git fetch origin main` to ensure you have the latest commits
+   - The workspace may be behind origin/main, causing you to miss recently merged PRs
+   - After fetching, use `origin/main` for all comparisons, NOT local `main` branch
+
+2. **Determine the correct version tag to compare against**:
    - First, check the tag dates: `git log --tags --simplify-by-decoration --pretty="format:%ai %d" | head -10`
    - Find the latest version tag and its date
-   - Compare main branch date to the tag date
-   - If the tag is NEWER than main, it means main needs to be updated to include the tag's commits
+   - Compare origin/main branch date to the tag date
+   - If the tag is NEWER than origin/main, it means the branch needs to be updated to include the tag's commits
    - **CRITICAL**: Always use `git log TAG..BRANCH` to find commits that are in the tag but not in the branch, as the tag may be ahead
 
-2. **Check commits and version boundaries**:
-   - Run `git log --oneline LAST_TAG..main` to see commits since the last release
-   - Also check `git log --oneline main..LAST_TAG` to see if the tag is ahead of main
+3. **Check commits and version boundaries**:
+   - **IMPORTANT**: Use `origin/main` in all commands below, not local `main`
+   - Run `git log --oneline LAST_TAG..origin/main` to see commits since the last release
+   - Also check `git log --oneline origin/main..LAST_TAG` to see if the tag is ahead of origin/main
    - If the tag is ahead, entries in "Unreleased" section may actually belong to that tagged version
-   - Identify which commits contain user-visible changes
-   - Extract PR numbers and author information from commit messages
-   - **Never ask the user for PR details** - get them from the git history
+   - **Extract ALL PR numbers** from commit messages using grep: `git log --oneline LAST_TAG..origin/main | grep -oE "#[0-9]+" | sort -u`
+   - For each PR number found, check if it's already in CHANGELOG.md using: `grep "PR #XXX" CHANGELOG.md`
+   - Identify which commits contain user-visible changes (look for keywords like "Fix", "Add", "Feature", "Bug", etc.)
+   - Extract author information from commit messages
+   - **Never ask the user for PR details** - get them from the git history or use WebFetch on the PR URL
 
-3. **Validate** that changes are user-visible (per the criteria above). If not user-visible, skip those commits.
+4. **Validate** that changes are user-visible (per the criteria above). If not user-visible, skip those commits.
 
-4. **Read the current CHANGELOG.md** to understand the existing structure and formatting.
+5. **Read the current CHANGELOG.md** to understand the existing structure and formatting.
 
-5. **Determine where entries should go**:
-   - If the latest version tag is NEWER than main branch, move entries from "Unreleased" to that version section
-   - If main is ahead of the latest tag, add new entries to "Unreleased"
+6. **Determine where entries should go**:
+   - If the latest version tag is NEWER than origin/main branch, move entries from "Unreleased" to that version section
+   - If origin/main is ahead of the latest tag, add new entries to "Unreleased"
    - Always verify the version date in CHANGELOG.md matches the actual tag date
 
-6. **Add or move entries** to the appropriate section under appropriate category headings.
+7. **Add or move entries** to the appropriate section under appropriate category headings.
    - **CRITICAL**: When moving entries from "Unreleased" to a version section, merge them with existing entries under the same category heading
    - **NEVER create duplicate section headings** (e.g., don't create two "### Fixed" sections)
    - If the version section already has a category heading (e.g., "### Fixed"), add the moved entries to that existing section
    - Maintain the category order as defined above
 
-7. **Verify formatting**:
+8. **Verify formatting**:
    - Bold description with period
    - Proper PR link
    - Proper author link
    - Consistent with existing entries
    - File ends with a newline character
 
-8. **Run linting** after making changes:
+9. **Run linting** after making changes:
 
    ```bash
    yarn lint
    ```
 
-9. **Show the user** the added or moved entries and explain what was done.
+10. **Show the user** the added or moved entries and explain what was done.
 
 ### For Beta to Non-Beta Version Release
 

CHANGELOG.md

@@ -9,16 +9,19 @@
 
 ## [Unreleased]
 
+Changes since the last non-beta release.
+
+## [v9.3.1] - November 9, 2025
+
 ### Fixed
 
+- **Fixed NODE_ENV not being set when running shakapacker-dev-server**. [PR #823](https://github.com/shakacode/shakapacker/pull/823) by [Seifeldin7](https://github.com/Seifeldin7). Resolves [#802](https://github.com/shakacode/shakapacker/issues/802). The dev server now properly initializes NODE_ENV to match RAILS_ENV (or "production" by default), fixing webpack configurations that dynamically load environment-specific files.
 - Extended manifest merging for multiple client configurations to all environments. [PR #800](https://github.com/shakacode/shakapacker/pull/800) by [Judahmeek](https://github.com/Judahmeek).
 
-Changes since the last non-beta release.
-
 ### Added
 
 - **Support for `css_modules_export_mode` configuration option**. [PR #817](https://github.com/shakacode/shakapacker/pull/817) by [justin808](https://github.com/justin808). Adds `css_modules_export_mode` setting in `shakapacker.yml` to control CSS Modules export style. Set to `"named"` (default, v9+ behavior with true named exports) or `"default"` (v8 behavior with default export object). Allows teams to opt into v8-style exports for easier migration from v8 or when using TypeScript with strict type checking.
-- **`Configuration#data` public API method** with enhanced documentation and safety. [PR #820](https://github.com/shakacode/shakapacker/pull/820) by [justin808](https://github.com/justin808). The `Configuration#data` method is now part of the public Ruby API, providing stable access to raw configuration data. Returns a frozen hash with symbolized keys to prevent accidental mutations. Includes comprehensive test coverage and detailed RDoc documentation.
+- **`Configuration#data` public API method** with enhanced documentation and safety. [PR #818](https://github.com/shakacode/shakapacker/pull/818) by [justin808](https://github.com/justin808). The `Configuration#data` method is now part of the public Ruby API, providing stable access to raw configuration data. Returns a frozen hash with symbolized keys to prevent accidental mutations. Includes comprehensive test coverage and detailed RDoc documentation.
 - **Support for `javascript_transpiler: 'none'`** for completely custom webpack configurations. [PR #799](https://github.com/shakacode/shakapacker/pull/799) by [justin808](https://github.com/justin808). Allows users with custom webpack configs to skip Shakapacker's transpiler setup and validation by setting `javascript_transpiler: 'none'` in `shakapacker.yml`. Useful when managing transpilation entirely outside of Shakapacker's defaults.
 
 ## [v9.3.0] - November 2, 2025
@@ -727,7 +730,8 @@ Note: [Rubygem is 6.3.0.pre.rc.1](https://rubygems.org/gems/shakapacker/versions
 
 See [CHANGELOG.md in rails/webpacker (up to v5.4.3)](https://github.com/rails/webpacker/blob/master/CHANGELOG.md)
 
-[Unreleased]: https://github.com/shakacode/shakapacker/compare/v9.3.0...main
+[Unreleased]: https://github.com/shakacode/shakapacker/compare/v9.3.1...main
+[v9.3.1]: https://github.com/shakacode/shakapacker/compare/v9.3.0...v9.3.1
 [v9.3.0]: https://github.com/shakacode/shakapacker/compare/v9.2.0...v9.3.0
 [v9.2.0]: https://github.com/shakacode/shakapacker/compare/v9.1.0...v9.2.0
 [v9.1.0]: https://github.com/shakacode/shakapacker/compare/v9.0.0...v9.1.0