Add a sh script to generate rc and update the composer.json file

[Honemo]

Description

Add local RC candidate generation tooling to streamline the release QA workflow.

This PR introduces a bin/build-zip.sh script that allows developers to generate a distribution ZIP locally — identical to what the deploy-tag.yml CI produces for SVN — without triggering a full release. It also promotes woocommerce/action-scheduler from a dev dependency to a production dependency, and ships an updated set of minified JS assets rebuilt with the correct toolchain.

Type of change

• New feature (non-breaking change which adds functionality).
• Bug fix (non-breaking change which fixes an issue).
• Enhancement (non-breaking change which improves an existing functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as before).
• Sub-task of #(issue number)
• Chore
• Release

Detailed scenario

What was tested

• Ran ./bin/build-zip.sh imagify-x.x.x-rc1.zip from the repo root on a local environment with Composer and Node available.
• Verified the resulting ZIP in generatedpackages/ matches the file layout produced by the CI pipeline (applies .distignore, strips dev-only paths such as /Tests, /bin, /.github).
• Confirmed generatedpackages/ is excluded from version control via the new .gitignore entry.
• Verified that dev dependencies are automatically restored after the ZIP is built (composer install is re-run at the end of the script).
• Confirmed woocommerce/action-scheduler ^3.4 is correctly declared under require and no longer listed under require-dev.

How to test

1. Checkout this branch.
2. Ensure Composer and Node (with npm) are installed locally.
3. Run:

   ./bin/build-zip.sh imagify-test.zip

4. Confirm a file is created at generatedpackages/imagify-test.zip.
5. Unzip and verify:
   • The imagify/ directory is present at the root of the archive.
   • Dev-only paths (Tests/, bin/, .github/, composer.json, etc.) are absent.
   • Vendor dependencies (including Strauss-namespaced files) are present.
   • Built JS assets are present under assets/js/.
6. Verify generatedpackages/ does not appear in git status.

Affected Features & Quality Assurance Scope

• Release / packaging pipeline only. No plugin runtime behaviour is changed.
• woocommerce/action-scheduler moving from require-dev to require ensures it is included in the production vendor directory; any code path that depends on it at runtime will now work correctly in production builds.

Technical description

Documentation

bin/build-zip.sh

The script follows the same steps as the deploy-tag.yml CI workflow:

1. Downloads strauss.phar once (cached in bin/) if not already present.
2. Runs composer install -o --no-dev to produce a production vendor directory (Strauss namespacing is applied by the Composer post-install hook).
3. Runs npm install && npm run build to compile front-end assets.
4. Copies the entire repo into a temp directory via rsync.
5. Walks through .distignore and removes every listed path from the temp copy.
6. Zips the resulting directory into generatedpackages/<zip-name>.
7. Cleans up the temp directory.
8. Restores dev dependencies by running composer install without --no-dev.

composer.json

woocommerce/action-scheduler ^3.4 is moved from require-dev to require. This was likely misplaced — Action Scheduler is a runtime dependency (background processing), not a tooling dependency.

.gitignore

/generatedpackages is added so that the output directory created by the script is never accidentally committed.

assets/js/*.min.js

All minified JS files have been rebuilt. The observable diff in admin.min.js shows an arrow-function IIFE ((a,i,e) => {...}) replaced with a standard function expression (function(a,i,e){...}), consistent with a change in the Babel/build target configuration to improve broader browser compatibility.

New dependencies

None at the runtime level beyond what was already in use. woocommerce/action-scheduler was already present in the project; this change solely corrects its placement in composer.json.

The script requires strauss.phar (downloaded automatically on first run), composer, npm, rsync, and zip to be available on the developer's machine.

Risks

• Accidental commit of generatedpackages/: mitigated by the new .gitignore entry.
• Divergence from CI packaging: the script intentionally mirrors the CI steps. Any future change to deploy-tag.yml should be reflected in build-zip.sh as well. Consider adding a comment in both files referencing each other.
• action-scheduler in production vendor: low risk — the library is already used in production. Moving it to require ensures it ships in the ZIP; previously it could have been silently absent in production builds.

Mandatory Checklist

Code validation

• I validated all the Acceptance Criteria. If possible, provide screenshots or videos.
• I triggered all changed lines of code at least once without new errors/warnings/notices.
• I implemented built-in tests to cover the new/changed code.

Code style

• I wrote a self-explanatory code about what it does.
• I protected entry points against unexpected inputs.
• I did not introduce unnecessary complexity.
• Output messages (errors, notices, logs) are explicit enough for users to understand the issue and are actionnable.

Unticked items justification

"I implemented built-in tests": the script is a standalone shell utility for local developer use. Automated tests for a packaging script would add complexity without meaningful safety gains; the build output is validated manually by inspecting the ZIP contents.

Additional Checks

• In the case of complex code, I wrote comments to explain it.
• When possible, I prepared ways to observe the implemented system (logs, data, etc.).
• I added error handling logic when using functions that could throw errors (HTTP/API request, filesystem, etc.)

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Coverage ∅ diff coverage · +0.00% coverage variation

Metric	Results
Coverage variation	✅ +0.00% coverage variation (-0.10%)
Diff coverage	✅ ∅ diff coverage (50.00%)

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (fd336fc)	18504	341	1.84%
Head commit (ffd40dd)	18504 (+0)	341 (+0)	1.84% (+0.00%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#1091)	0	0	∅ (not applicable)

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}