fix: Create PP Dev Updates – Security, Tooling & Bug Fixes

[sergak01]

This PR merges the latest develop changes into main, bringing security improvements, Cursor workflow rules, build enhancements, and critical TypeScript/runtime bug fixes to the create-pp-dev scaffold.

✨ Key Features & Improvements

• Security - Add minimatch override and upgrade packages to address vulnerabilities
• Build - Add postbuild script to produce -latest.tgz for easier local installs
• Cursor Rules - Add Create PR and Create release rules for consistent workflow
• TypeScript Fixes - Resolve validate callback types, p.select generic, and spawn.sync usage
• Vanilla Templates - Fix pkgJson.dependencies handling when adding pp-components
• Dependencies - Downgrade ESLint to 9.0.0 for template compatibility

📊 Impact Summary

• 11 files changed across templates, scripts, and core scaffold
• 765 insertions, 877 deletions – Net reduction from lockfile cleanup
• Templates updated – React, Next.js, Vanilla, Vanilla-TS package.json improvements

🔄 Breaking Changes

• None - All changes maintain backward compatibility

🧪 Testing & Quality Assurance

• TypeScript compiles without errors (tsc --noEmit)
• Build succeeds with unbuild and postbuild
• Templates scaffold correctly for all frameworks

📝 Included Commits

• ee27478 fix(deps): add minimatch override and upgrade packages for security
• 14141f8 chore: add postbuild script and gitignore for latest tgz
• 029973e feat(cursor): add Create PR and Create release rules
• c7c6c5f chore(deps-dev): downgrade eslint to version 9.0.0
• b994e40 fix: resolve TypeScript errors and runtime bugs in create-pp-dev
• bdd109d Merge pull request PP-2787 fix(deps): Security Updates, Dependency Upgrades & Cursor Rules #51 from mi-examples/pp-2787-updates

🏷️ Release Notes

• Improved security posture with dependency overrides
• Smoother developer experience with Cursor rules and latest tgz artifact
• Fixed scaffold reliability for vanilla projects and package install step

✅ Ready for Main

• All changes tested and merged via pp-2787-updates
• Ready for production release

Summary by CodeRabbit

• Chores

  • Bumped version to 0.6.0-beta.1
  • Updated Node.js requirement to >=22.0.0 and npm to >=10.0.0
  • Updated dependencies across all templates and core packages
  • Added minimatch override for dependency resolution
  • Implemented automated tarball archival post-build

• Documentation

  • Added PR generation workflow guide
  • Added release tag creation workflow guide

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR prepares a release for version 0.6.0-beta.1, including version bumping, workflow documentation for PR and release creation, a postbuild script for tarball management, dependency updates across the root and template packages, and minor validation improvements in the main source code.

Changes

Cohort / File(s)	Summary
Workflow Documentation .cursor/rules/create-pr.mdc, .cursor/rules/create-release.mdc	New Markdown-based workflow definitions for generating PR messages from branch diffs and creating release tags from package.json versions, with optional push steps.
Release Metadata CHANGELOG.md, .gitignore	Added 0.6.0-beta.1 changelog entry with bug fixes and features; added pattern to ignore latest pack file variant.
Root Package Configuration package.json	Bumped version to 0.6.0-beta.1, added npm >=10.0.0 engine requirement, added postbuild script, introduced minimatch override, and updated devDependencies and dependencies.
Template Package Configuration template-nextjs/package.json, template-react/package.json, template-vanilla-ts/package.json, template-vanilla/package.json	Aligned engine requirements to Node >=22.0.0 and npm >=10.0.0; added minimatch override; updated devDependencies and minor dependency versions across all templates.
Build Script scripts/postbuild.js	New script that creates a "-latest" tarball copy after npm pack, enabling easy access to the most recent build artifact.
Source Code Improvements src/index.ts	Enhanced project and package name validation, simplified framework type definition, ensured dependencies object exists before package additions, and fixed install command invocation with proper argument splitting.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• chore(deps): update pp-dev to 0.13.2 #35: Bumps @metricinsights/pp-dev to 0.14.0 across package.json files, aligning with dependency version updates in this PR.
• chore(deps): update pp-dev to 0.13.1 #8: Updates @metricinsights/pp-dev across template package.json files, consistent with the dependency upgrade pattern in this release.

Poem

🐰 A release hops into view, v0.6.0 takes flight,
With workflows and tarballs all packed up tight,
Dependencies dance to a newer refrain,
Templates aligned from valley to plain,
The latest pack flies, our build tools shine bright! 🚀

🚥 Pre-merge checks | ✅ 1 | ❌ 2

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.
Title check	❓ Inconclusive	The title partially addresses the changeset's main improvements (security, tooling, bug fixes) but oversimplifies a complex multi-faceted release with workflow automation, dependency upgrades, and bug corrections. It uses vague framing ('Updates') without clarifying the primary driver.	Clarify the title to emphasize the most important change—either the security fixes via minimatch override, the postbuild workflow addition, or the version bump to 0.6.0-beta.1—for improved clarity and specificity.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

• 📝 Generate docstrings (stacked PR)
• 📝 Generate docstrings (commit on current branch)

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch develop

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 5

🧹 Nitpick comments (3)

template-nextjs/package.json (1)

19-22: Pinned next / eslint-config-next versions won't receive automatic security patches.

next: "16.1.6" and eslint-config-next: "16.1.6" are exact-pinned (no ^). While pinning is acceptable in a scaffold template (users are expected to run npm update post-scaffold), critical security patches (e.g., the RSC CVEs addressed in 16.x patches) won't be pulled in automatically. Consider "^16.1.6" so that patch upgrades are picked up on npm install in the generated project.

🔧 Suggested change

-    "next": "16.1.6",
+    "next": "^16.1.6",
 ...
-    "eslint-config-next": "16.1.6",
+    "eslint-config-next": "^16.1.6",

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@template-nextjs/package.json` around lines 19 - 22, Update the exact-pinned
Next.js and ESLint Next config dependencies in package.json so they allow patch
updates: change the "next" and "eslint-config-next" entries from exact versions
(e.g., "16.1.6") to caret ranges (e.g., "^16.1.6") so npm install will pick up
security patches automatically in generated projects.

.cursor/rules/create-release.mdc (1)

19-37: Add a note clarifying the relationship to semantic-release to avoid tag conflicts.

This workflow creates tags manually on origin/main. Since the project uses semantic-release for automated versioning, manually pushed tags using the same v<version> format can skew semantic-release's next-version calculation (it scans existing tags to compute the release range). Consider adding a note to the workflow instructing the AI to verify that the tag doesn't already exist and to document that this path is for manual promotions only (e.g., promoting a beta to stable outside the CI pipeline). Based on learnings, "Use semantic-release for automated versioning with all releases going through Pull Requests (no direct pushes to main)."

📝 Suggested note addition

 ## Notes
 
 - Tag is created from `origin/main`, not from the current branch.
 - Do not push the tag unless the user explicitly requests it.
 - Confirm the version and tag name with the user before creating/pushing.
+- This workflow is for manual promotions (e.g., beta → stable) only. For automated releases, defer to the semantic-release CI pipeline. Verify the tag does not already exist (`git tag -l v<version>`) before creating.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.cursor/rules/create-release.mdc around lines 19 - 37, Add a clarification
to the release instructions that this manual tagging flow interacts with
semantic-release: explicitly state that semantic-release is the authoritative
automated versioner and that manual tags using the v<version> format can affect
its next-version calculation; instruct the agent to first check for existing
tags (ensure v<version> does not already exist) before creating/pushing, and
mark this workflow as "manual promotions only" (e.g., promoting a pre-release to
stable outside CI) with a clear admonition to prefer semantic-release and avoid
direct pushes to origin/main except when explicitly authorized.

package.json (1)

34-34: postbuild lifecycle hook runs npm pack on every npm run build invocation.

Because postbuild is an npm lifecycle name, it fires automatically after build. Combined with prepublishOnly: "npm run build", a single npm publish call triggers two pack operations — one in postbuild and one internally by npm publish. Over time, versioned .tgz files will accumulate in the repository root (mitigated by .gitignore, but still present on disk). Consider renaming the script (e.g. "pack-latest") and invoking it explicitly to limit packing to intentional invocations.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@package.json` at line 34, The postbuild script currently runs "npm pack"
automatically after every build because the script key is named "postbuild";
rename this script (e.g., change "postbuild" to "pack-latest") and update any
CI/publish scripts that need packing to call the new script explicitly, and
leave the lifecycle "prepublishOnly": "npm run build" untouched so npm publish
still builds but packing only happens when you intentionally run "npm run
pack-latest"; ensure references to the old "postbuild" key are removed and
update package.json scripts accordingly.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@CHANGELOG.md`:
- Around line 1-13: The changelog entry uses a top-level h1 for the version
header ("# [0.6.0-beta.1]...") while the sections below use h3 ("### Bug Fixes",
"### Features"), causing an MD001 heading level skip; change the version header
to h2 by replacing the leading "#" with "##" so it matches the existing
convention (version headers as "##" and sections as "###") for the entry
containing "[0.6.0-beta.1]".

In `@scripts/postbuild.js`:
- Around line 13-35: The current file selection can include an existing
"*-latest.tgz" so latest may equal the already-latest file and the replace regex
won't change the name, causing copyFileSync to copy a file onto itself; update
the filter that builds tgzFiles to explicitly exclude files ending with
"-latest.tgz" (e.g. add a condition like !f.endsWith("-latest.tgz") or
!/-latest\.tgz$/.test(f)), and also add a safety check before copyFileSync to
skip copying when destPath === latest.path (or latestNameNew === latestName) to
prevent self-overwrite; reference tgzFiles, latestNameNew and copyFileSync when
making these changes.

In `@template-nextjs/package.json`:
- Around line 14-16: Update the package.json "engines" constraint to require
Node 22.13.0 or newer so ESLint 10.0.1 can be installed: locate the "engines"
object in package.json and change the "node" value from ">=22.0.0" to
">=22.13.0" (leave the "npm" entry untouched); this ensures compatibility with
eslint's required node ranges.

In `@template-vanilla-ts/package.json`:
- Around line 14-15: The engines.node field currently set to ">=22.0.0" and use
of .eslintrc.cjs are incompatible with ESLint 10 (which requires Node >=22.13.0
and flat config); either: A) update engines.node to ">=22.13.0" (or ">=20.19.0"
if Node 20 support is desired) and migrate .eslintrc.cjs to a flat config file
named eslint.config.js (recommend using npx `@eslint/migrate-config`), or B) keep
engines.node as ">=22.0.0" and remain on ESLint 9 by ensuring the package.json
and lockfile reference ESLint 9 so .eslintrc.cjs continues to be used. Ensure
the chosen option updates package.json engines.node and the repository config
file (.eslintrc.cjs → eslint.config.js) consistently.

In `@template-vanilla/package.json`:
- Around line 14-15: The engines declaration in template-vanilla/package.json
("node": ">=22.0.0") conflicts with the installed eslint version constraint;
update package.json to resolve the ESLint/Node gap by either raising the Node
engine floor to at least ">=22.13.0" or pinning the "eslint" dependency to a v9
range (e.g., "^9.x") so users on Node 22.0.0–22.12.x aren't broken; modify the
"node" engines entry or the "eslint" entry accordingly and run a quick install
to verify no new engine mismatch errors occur.

---

Nitpick comments:
In @.cursor/rules/create-release.mdc:
- Around line 19-37: Add a clarification to the release instructions that this
manual tagging flow interacts with semantic-release: explicitly state that
semantic-release is the authoritative automated versioner and that manual tags
using the v<version> format can affect its next-version calculation; instruct
the agent to first check for existing tags (ensure v<version> does not already
exist) before creating/pushing, and mark this workflow as "manual promotions
only" (e.g., promoting a pre-release to stable outside CI) with a clear
admonition to prefer semantic-release and avoid direct pushes to origin/main
except when explicitly authorized.

In `@package.json`:
- Line 34: The postbuild script currently runs "npm pack" automatically after
every build because the script key is named "postbuild"; rename this script
(e.g., change "postbuild" to "pack-latest") and update any CI/publish scripts
that need packing to call the new script explicitly, and leave the lifecycle
"prepublishOnly": "npm run build" untouched so npm publish still builds but
packing only happens when you intentionally run "npm run pack-latest"; ensure
references to the old "postbuild" key are removed and update package.json
scripts accordingly.

In `@template-nextjs/package.json`:
- Around line 19-22: Update the exact-pinned Next.js and ESLint Next config
dependencies in package.json so they allow patch updates: change the "next" and
"eslint-config-next" entries from exact versions (e.g., "16.1.6") to caret
ranges (e.g., "^16.1.6") so npm install will pick up security patches
automatically in generated projects.

---

ℹ️ Review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8ca7135 and 48d2987.

⛔ Files ignored due to path filters (1)

• package-lock.json is excluded by !**/package-lock.json

📒 Files selected for processing (11)

• .cursor/rules/create-pr.mdc
• .cursor/rules/create-release.mdc
• .gitignore
• CHANGELOG.md
• package.json
• scripts/postbuild.js
• src/index.ts
• template-nextjs/package.json
• template-react/package.json
• template-vanilla-ts/package.json
• template-vanilla/package.json