MokoConsulting/Template-NPM
Template
1
0
Fork 0
Code Issues 6 Pull Requests Releases Wiki Activity

ci: release workflows — npm setup + archive from source dir (not dist) #35

New Issue
Open
opened 2026-07-18 17:03:37 +00:00 by jmiller · 2 comments
jmiller commented 2026-07-18 17:03:37 +00:00
Owner
Copy Link
Copy Source

Summary

Audit and fix the release workflows so npm/MCP repos have a correct Node/npm setup and so the release archive is built from the source directory (per design), not from dist/.

Findings

  • npm-auto-release.yml: has setup-node + npm ci + npm run build, but:
    • Line ~148 archives from dist: tar -czf "…tar.gz" -C dist . — this contradicts "the release system zips from the source directory."
    • Path filter and tool-count hardcode src/** and src/index.ts.
    • No registry-url configured.
  • pre-release.yml: PHP/Joomla-only (installs php-cli, mbstring, composer); zero Node/npm setup. If npm repos inherit this generic pre-release, they have no Node path.

Requirements

  1. npm-auto-release.yml:
    • Consume the resolve-source-dir composite action; archive from the resolved source_dir instead of dist.
    • Replace hardcoded src/** / src/index.ts with the resolved dir (entry file derived from it).
    • Add registry-url: 'https://registry.npmjs.org' where npm auth is needed; verify Node setup is complete for the release path.
  2. pre-release.yml: decide the npm path — either gate the PHP/Joomla steps to Joomla repos and add a Node-aware branch, or split out a dedicated npm-pre-release.yml. Ensure any release workflow that runs for npm repos performs setup-node → install → build.
  3. Preserve Copyright + SPDX headers on all edited workflow files.

Acceptance Criteria

  • npm-auto-release.yml archives from the resolved source dir (not dist).
  • No hardcoded src/ literal remains in npm-auto-release.yml.
  • registry-url present where npm publish/auth occurs.
  • A release run on an npm repo has a complete Node/npm setup (no reliance on the PHP-only pre-release.yml).
  • Headers preserved.

Notes

  • Consumes the resolve-source-dir composite action (metadata source-dir resolver issue). Author in parallel; merge the resolver first so CI references resolve.

Authored-by: Moko Consulting

## Summary Audit and fix the release workflows so npm/MCP repos have a correct Node/npm setup **and** so the release archive is built **from the source directory** (per design), not from `dist/`. ## Findings - **`npm-auto-release.yml`**: has `setup-node` + `npm ci` + `npm run build`, **but**: - Line ~148 archives from `dist`: `tar -czf "…tar.gz" -C dist .` — this contradicts "the release system zips from the source directory." - Path filter and tool-count hardcode `src/**` and `src/index.ts`. - No `registry-url` configured. - **`pre-release.yml`**: PHP/Joomla-only (installs `php-cli`, `mbstring`, `composer`); **zero Node/npm setup**. If npm repos inherit this generic pre-release, they have no Node path. ## Requirements 1. **`npm-auto-release.yml`**: - Consume the `resolve-source-dir` composite action; archive from the resolved `source_dir` instead of `dist`. - Replace hardcoded `src/**` / `src/index.ts` with the resolved dir (entry file derived from it). - Add `registry-url: 'https://registry.npmjs.org'` where npm auth is needed; verify Node setup is complete for the release path. 2. **`pre-release.yml`**: decide the npm path — either gate the PHP/Joomla steps to Joomla repos and add a Node-aware branch, or split out a dedicated `npm-pre-release.yml`. Ensure any release workflow that runs for npm repos performs `setup-node` → install → build. 3. Preserve Copyright + SPDX headers on all edited workflow files. ## Acceptance Criteria - [ ] `npm-auto-release.yml` archives from the resolved source dir (not `dist`). - [ ] No hardcoded `src/` literal remains in `npm-auto-release.yml`. - [ ] `registry-url` present where npm publish/auth occurs. - [ ] A release run on an npm repo has a complete Node/npm setup (no reliance on the PHP-only `pre-release.yml`). - [ ] Headers preserved. ## Notes - Consumes the `resolve-source-dir` composite action (metadata source-dir resolver issue). Author in parallel; merge the resolver first so CI references resolve. Authored-by: Moko Consulting
jmiller added the size/mci-cdstandards-drifttypescript labels 2026-07-18 17:03:37 +00:00
jmiller commented 2026-07-18 17:14:22 +00:00
Author
Owner
Copy Link
Copy Source

Scope refinement (release artifacts): npm releases must attach two ZIP artifacts, mirroring the Joomla release convention:

  1. Full-repo standard zip — ${REPO_NAME}-${VERSION}.zip — the whole repository (tracked files only; no .git/node_modules/dist). Built via git archive --format=zip HEAD.
  2. Source zip — ${REPO_NAME}-${VERSION}-source.zip — the resolved source-directory subtree only (like Joomla's element zip). Built via git archive --format=zip HEAD:<resolved_source_dir>.

Both are uploaded to the release. This replaces the single .tar.gz artifact. Packaging must run after the release/version-badge commit so both zips reflect the released tree.

Authored-by: Moko Consulting

**Scope refinement (release artifacts):** npm releases must attach **two ZIP artifacts**, mirroring the Joomla release convention: 1. **Full-repo standard zip** — `${REPO_NAME}-${VERSION}.zip` — the whole repository (tracked files only; no `.git`/`node_modules`/`dist`). Built via `git archive --format=zip HEAD`. 2. **Source zip** — `${REPO_NAME}-${VERSION}-source.zip` — the resolved source-directory subtree only (like Joomla's element zip). Built via `git archive --format=zip HEAD:<resolved_source_dir>`. Both are uploaded to the release. This replaces the single `.tar.gz` artifact. Packaging must run **after** the release/version-badge commit so both zips reflect the released tree. Authored-by: Moko Consulting
jmiller commented 2026-07-18 18:25:24 +00:00
Author
Owner
Copy Link
Copy Source

Status: implemented, pending testing (merged to dev via PR #38, promoted to main via #39).

Testing checklist (run npm-auto-release.yml in a child repo):

  • Release attaches two zips: ${REPO}-${VERSION}.zip (full repo) and ${REPO}-${VERSION}-source.zip (source subtree).
  • Source zip contains the source/ contents; full-repo zip excludes .git/node_modules.
  • A forced gh release upload failure fails the job (no green release with missing artifacts).
  • Empty/. resolved source dir → job errors instead of shipping a misleading source zip.
  • pre-release.yml on an npm repo emits the "not applicable" notice and does not install the PHP toolchain or call php.

Authored-by: Moko Consulting

**Status: implemented, pending testing** (merged to `dev` via PR #38, promoted to `main` via #39). Testing checklist (run `npm-auto-release.yml` in a child repo): - [ ] Release attaches **two zips**: `${REPO}-${VERSION}.zip` (full repo) and `${REPO}-${VERSION}-source.zip` (source subtree). - [ ] Source zip contains the `source/` contents; full-repo zip excludes `.git`/`node_modules`. - [ ] A forced `gh release upload` failure **fails the job** (no green release with missing artifacts). - [ ] Empty/`.` resolved source dir → job errors instead of shipping a misleading source zip. - [ ] `pre-release.yml` on an npm repo emits the "not applicable" notice and does **not** install the PHP toolchain or call `php`. Authored-by: Moko Consulting
Sign in to join this conversation.
Labels
Clear labels
breaking-change
Breaking API or behavior change
 ci-cd
CI/CD pipeline changes
 config
Configuration changes
 dependencies
Dependency updates
 deploy-failure
Deployment failed
 docker
Docker/container changes
 documentation
Documentation changes
 good first issue
Good for newcomers
 health-check
Repo health check result
 help wanted
Extra attention needed
 javascript
JavaScript code
 mokostandards
Related to MokoStandards framework
 push-failure
Git push operation failed
 security
Security vulnerability or hardening
 size/l
200-500 lines changed
 size/m
50-200 lines changed
 size/s
10-50 lines changed
 size/xl
500+ lines changed
 size/xs
< 10 lines changed
 standards-drift
Deviates from MokoStandards
 standards-update
MokoStandards compliance update
 sync-failure
Sync or mirror failed
 typescript
TypeScript code
 work-in-progress
Draft or incomplete work
bug
Something is not working
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 wontfix
This won't be fixed
No labels ci-cd size/m standards-drift typescript
Priority Medium
Type Feature
Milestone
No items
No Milestone
Assignees
Clear assignees
jmiller (Jonathan Miller)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: MokoConsulting/Template-NPM#35
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?