README

Environment to maintain a Merak component. Static classes that merak-cli (flags) and the composer.json of each Merak plugin or theme (scripts) call from the project root.

Scripts

Every script that changes files accepts -- --dry-run when it runs from composer (composer run update_composer -- --dry-run): it reports what it would change and writes nothing.

Composer script	Class	What it does
`version`	`MerakEnv\Version::update`	Propagates the `Version:` of the main file to `README.md`, `package.json`, `composer.json` and `phpunit.xml`.
`version` (chained)	`MerakEnv\Header::copyrightScript`	Copyright year range: first commit year to the current year. Runs together with the version bump.
`update_header`	`MerakEnv\Header::wordpressScript`	WordPress compatibility, only when the user asks: `Requires at least` (added when missing, never changed), `Tested up to` (installed WordPress version) and the README. Needs wp-cli.
`update_copyright`	`MerakEnv\Header::copyrightScript`	The copyright step alone. Needs git.
`update_composer`	`MerakEnv\Composer::updateScript`	Leaves what the framework owns in `composer.json` equal to the reference: `archive > exclude`, the scripts above and the `baxtian/merak-env` constraint.

"scripts": {
    "version": [
        "MerakEnv\\Version::update",
        "MerakEnv\\Header::copyrightScript"
    ],
    "update_header": "MerakEnv\\Header::wordpressScript",
    "update_copyright": "MerakEnv\\Header::copyrightScript",
    "update_composer": "MerakEnv\\Composer::updateScript"
}

Libs of apps built in another repo

A project that integrates an app built elsewhere (Vue, React…) points its assets/libs/{lib}/lib.json at the app's build with source (see the Build section of the baxtian/merak README). MerakEnv\Libs::sync registers the app's version in those entries, as app_version, which the production build of the project compares with the app's own package.json:

"scripts": {
    "sync-libs": "MerakEnv\\Libs::syncScript"
}

Run it after building the app and before building the project; -- --dry-run reports without writing. For every app whose version changed it also brings its CHANGELOG.md entries (between the version registered before and the new one) into the project's CHANGELOG.md and design/historial.md, marked 🔄✂️ until they are summarized (MerakEnv\Changelog; a file that does not exist is skipped), and refreshes design/avisos.json with verificar.py of the analisis-interactivo skill when it is installed. A * in the file name (the same in the key) stands for the hash of an app's entry and must match one file. The version registered is the one the build declares in its version.json ({"version":"x.y.z"}, written by the app's build from its package.json); a lib whose package.json says another version is not registered. A build without version.json falls back to the date: a package.json newer than the build is not registered. and an unresolved source adds a warning. The script is not part of the reference scripts that update_composer manages: add it only to a project that has libs with source.

Run the tests with composer test.

Other classes: Libs (also regenerates lib.json), Blocks, Src (entry points and Instances.php), SilenceIsGold, Dist (zip), Svn.

`composer.json`

MerakEnv\Composer::update() brings three things to the reference and rewrites only those parts, so the rest of the file keeps its format. It is the way to reach a project that does not have the scripts yet (merak --update_composer works without them).

archive > exclude (Composer::EXCLUDE): all entries start with /, so they are resolved from the project root and never touch the files of the dependencies in vendor/. It replaces the old patterns (composer.* → /composer.*, the webpack.* ones → /webpack.* and /vendor/baxtian/merak/config/, merak-env → /vendor/baxtian/merak-env/), adds what is missing and keeps the project's own entries at the end.
scripts (Composer::SCRIPTS): version, update_header, update_copyright and update_composer are added when missing and replaced when different. The other scripts of the project are not touched.
baxtian/merak-env: a ^0.7.x constraint below ^0.7.14 is raised to it; run composer update baxtian/merak-env afterwards.

Header

MerakEnv\Header has three entry points: wordpress(), copyright() and update() (both). They return ['changes' => [...], 'warnings' => [...]]; a missing wp-cli or git adds a warning and skips the step that needs it.

Messages and translation

The library writes its messages in English and does not translate them. A caller that wants to translate (merak-cli does) uses the codes: the fixed entries of warnings are keyed by a code (no_wp_cli, wp_version, no_git, no_git_history in Header; no_archive, no_scripts, no_merak_env, run_update, exclude_not_rewritten, invalid_json, invalid_result in Composer), and errors are MerakEnvException with a code (MerakEnvException::NO_*) and getContext() for the values of the message.

baxtian / merak-env

Package info

Security

Statistics