README

This is for PHP package authors to require in their composer.json. It will install their package to the correct location based on the specified package type.

The goal of Installers is to be a simple package type to install path map. Users can also customize the install path per package and package authors can modify the package name upon installing.

HostCMS: optional SkyNet Geo scaffold

The plugin can create a project connector from the templates shipped by skynet/core-module. Both packages need versions containing this feature. Enable it explicitly in the root project, preserving other configuration:

{
  "config": {"allow-plugins": {"skynet/installers": true}},
  "extra": {"skynet-geo": {"scaffold": true, "module": "um"}}
}

After install/update, an interactive run asks before creating missing files in modules/um/geo. No is the default: Enter or n skips scaffolding without failing the installation or changing project files/configuration. If module is omitted, the plugin asks for it; an empty answer also declines. Complete existing connectors need no prompt. Noninteractive runs scaffold only when both scaffold=true and module are explicitly configured; a missing target is skipped. To disable future prompts, set scaffold=false or remove the section. Interactive decisions apply to the current run and do not rewrite composer.json.

Optional "web-root": "public" chooses an existing public directory inside the Composer project; it does not change package installation paths. Existing files and project edits are preserved. Removing SkyNet never removes the project connector. No configuration means no scaffold work; generated protection remains disabled. The callback never boots HostCMS, changes nginx or creates runtime policies/secrets.

The handler uses POST_INSTALL_CMD/POST_UPDATE_CMD, also when packages are already installed. Composer --dry-run does not scaffold. --no-scripts does not disable plugin subscribers; use --no-plugins or set scaffold=false to skip this handler. Existing custom installers and their locations are unchanged.

For a manual command, root-script fallback and setup instructions, see modules/skynetcore/docs/geo/README.md and the generated connector README.

Installers isn't intended on replacing all custom installers. If your package requires special installation handling then by all means, create a custom installer to handle it.

Natively Supported Frameworks:

The following frameworks natively work with Composer and will be installed to the default vendor directory. composer/installers is not needed to install packages with these frameworks:

• Aura
• Symfony2
• Yii
• Yii2

Current Supported Package Types

Stable types are marked as bold, this means that installation paths for those type will not be changed. Any adjustment for those types would require creation of brand new type that will cover required changes.

Example composer.json File

This is an example for a CakePHP plugin. The only important parts to set in your composer.json file are "type": "cakephp-plugin" which describes what your package is and "require": { "composer/installers": "~1.0" } which tells composer to load the custom installers.

{
    "name": "you/ftp",
    "type": "cakephp-plugin",
    "require": {
        "composer/installers": "~1.0"
    }
}

This would install your package to the Plugin/Ftp/ folder of a CakePHP app when a user runs php composer.phar install.

So submit your packages to packagist.libfun.net!

Custom Install Paths

If you are consuming a package that uses the composer/installers you can override the install path with the following extra in your composer.json:

{
    "extra": {
        "installer-paths": {
            "your/custom/path/{$name}/": ["shama/ftp", "vendor/package"]
        }
    }
}

A package type can have a custom installation path with a type: prefix.

{
    "extra": {
        "installer-paths": {
            "your/custom/path/{$name}/": ["type:wordpress-plugin"]
        }
    }
}

You can also have the same vendor packages with a custom installation path by using the vendor: prefix.

{
    "extra": {
        "installer-paths": {
            "your/custom/path/{$name}/": ["vendor:my_organization"]
        }
    }
}

These would use your custom path for each of the listed packages. The available variables to use in your paths are: {$name}, {$vendor}, {$type}.

Custom Install Names

If you're a package author and need your package to be named differently when installed consider using the installer-name extra.

For example you have a package named shama/cakephp-ftp with the type cakephp-plugin. Installing with composer/installers would install to the path Plugin/CakephpFtp. Due to the strict naming conventions, you as a package author actually need the package to be named and installed to Plugin/Ftp. Using the following config within your package composer.json will allow this:

{
    "name": "shama/cakephp-ftp",
    "type": "cakephp-plugin",
    "extra": {
        "installer-name": "Ftp"
    }
}

Please note the name entered into installer-name will be the final and will not be inflected.

Should we allow dynamic package types or paths? No.

What are they? The ability for a package author to determine where a package will be installed either through setting the path directly in their composer.json or through a dynamic package type: "type": "framework-install-here".

It has been proposed many times. Even implemented once early on and then removed. Installers won't do this because it would allow a single package author to wipe out entire folders without the user's consent. That user would then come here to yell at us.

Anyone still wanting this capability should consider requiring https://github.com/oomphinc/composer-installers-extender.

Проверка обновления Packagist

Workflow Update Packagist уведомляет Packagist после push в настроенные ветки и при публикации тегов. Для уведомления нужны секреты PACKAGIST_USERNAME и PACKAGIST_SAFE_TOKEN; публичный URL пакета уже указан в workflow.

Эта заметка добавлена для тестового запуска: после push проверьте шаг Notify Packagist в CI/CD и соответствие коммита на Packagist.

Повторная проверка доставки обновлений: для нового тестового коммита сверяйте результат отдельного запуска Update Packagist, а не предыдущего workflow.

The published standalone generator and manual CLI are preserved; compatibility and the automatic selection of one generator are described in GEO-SCAFFOLD.md.