Anybody knows how to composer install for all subfolders too? Does the composer support it? Now I need to execute this command in each subfolder or add all subfolder's vendor folder to git.
I found solution in Linux:
https://www.bram.us/2014/02/16/installing-dependencies-in-all-subfolder-organised-projects/
But how to do the same in Windows?
Example.
I have a project in C:\grav with composer.json in it.
But also I have plugins folder C:\grav\user\plugins with composer.json in some of subfolders:
I want to execute composer install in C:\grav to install all dependencies in each C:\grav\user\plugins\* too.
Grav plugin or theme
In order to support the correct installation folders for Grav plugins and themes,
you would need to add the composer/installers to the require section of your plugins.
Normally the plugins would land in the vendor folder, too - but, the Grav Installer tells Composer the correct position inside a Grav project, see
see https://github.com/composer/installers/blob/master/src/Composer/Installers/GravInstaller.php#L6
So, when writing plugins or themes for grav each composer.json must indicate the type as grav-plugin or grav-theme, else Composer can't match the package to the installer.
{
"name": "your/some-grav-plugin",
"type": "grav-plugin",
"require": {
"composer/installers": "^1.0.23"
}
}
Grav main project
Now, in your main grav project's composer.json, just add the plugins.
Then run composer install. That means the package is fetched, the composer installer is fetched, based on the package type the matching installer is triggered and the grav installer drops the file into the correct folder....
But how to do the same in Windows?
Uhm... Composer works cross-platform. Not a problem.
Related
I wanted to get several Git repositories then place it on a certain directory on my Git-tracked project. My current project structure:
- custom
- plugins
- file.txt
When the user do a composer install, I wanted it to fetch this Git repo then place it under new directory on my project named provisioning.
- custom
- plugins
- provisioning
- nginx
- file.txt
Am I using the Composer the right way?
By default, the composer will install dependencies to vendor directory. If you need to install everything into directory names provisioning the use
"config": {
"vendor-dir": "plugins"
},
in your composer.json file and then run composer install command
Further details in How to specify Composer install path?
I was working with a laravel project and, accidentally, removed vendor folder.
What should I do? Create a new project and copy it or download it anywhere else?
I had no additional composer dependencies installed.
Just run composer install after cding into the Laravel project's directory.
The Vendor folder is created by running composer install. It contains only the packages which you have asked composer to track in the composer.json file. If you have a composer.phar file in the root of your application run php composer.phar install.
https://getcomposer.org/doc/00-intro.md is probably your best source for additional information.
Basic question about composer. I would like to test composer and install jquery with it.
I created a composer.json file inside a project subfolder (project_root/test).
{
"require": {
"components/jquery": "^1.11.2"
}
}
Then I opened command prompt (with path = 'project_root/test' = same folder of composer.json) and executed:
composer install
Problem: composer installs NOT ONLY jquery but also symfony and some other stuff.
It's true that I have a symfony project in another folder (totally different folder with different path) which is "under composer"... it seems that composer is "mixing" the two projects.
Any ideas?
P.s. I installed composer with the windows installer (I think it's called global install)
Looking on Packagist, it seems that the version of components/jquery you want to install requires another package (robloach/component-installer), which then requires some other things, which require more things, etc. Eventually, it looks like you end up getting to symphony.
Composer is recursive in that it installs not just the things your package requires, but anything that those things require, etc. This is why you are getting symphony.
I see there is already a question but it did not answer the question
How can I install a composer package into the /src dir?
How can I install a bundle in the /src directory?
Reason I would like to do this is for development and deployment, so
I don't have to check in Symfony's base code into my subversion repo
I could use Composer to deploy
Looking over the Composer docs some more I did come across this:
http://getcomposer.org/doc/04-schema.md#config
vendor-dir: Defaults to vendor. You can install dependencies into a
different directory if you want to.
Could I set this at a Bundle level? or is this for the overall install?
https://github.com/composer/composer/blob/master/res/composer-schema.json
I know this is late, but in case anyone is searching for an answer that I painstakingly (hours and hours) found: vendor-dir
The documentation says:
By setting this var you can make composer install the dependencies into a directory other than vendor
Example:
{
"config": {
"vendor-dir": "website/password/vendor/"
}
}
From this doc and this doc
Again, hope to save anyone else a couple hours.
{
"extra": {
"installer-paths": {
"sites/example.com/modules/{$name}": ["vendor/package"]
}
}
}
Read more.
If you find composer's custom installers too complex or rigid, and you can plan what types of systems you will be deploying to, you might consider using post-install scripts.
Here's an example that creates a symlink from a package installed under vendors to the location where it might be expected:
"scripts": {
"post-install-cmd": [
"test -d vendor/foo/bar && ln -s ../vendor/foo/bar lib/bar"
]
}
This will create a symlink at lib/bar/ pointing to vendor/foo/bar/.
I have implemented this composer plugin to install packages into user (custom) defined folders you can just include it in your composer.json, follow the example and tell me if you have more questions :)
https://github.com/mnsami/composer-custom-directory-installer
composer-custom-directory-installer
A composer plugin, to install differenty types of composer packages in custom directories outside the default composer default installation path which is in the vendor folder.
This is not another composer-installer library for supporting non-composer package types i.e. application .. etc. This is only to add the flexability of installing composer packages outside the vendor folder. This package only supports composer package types,
https://getcomposer.org/doc/04-schema.md#type
The type of the package. It defaults to library.
Package types are used for custom installation logic. If you have a package that needs some special logic, you can define a custom type. This could be a symfony-bundle, a wordpress-plugin or a typo3-module. These types will all be specific to certain projects, and they will need to provide an installer capable of installing packages of that type.
How to use
Include the composer plugin into your composer.json require section::
"require":{
"php": ">=5.3",
"mnsami/composer-custom-directory-installer": "1.1.*",
"monolog/monolog": "*"
}
In the extra section define the custom directory you want to the package to be installed in::
"extra":{
"installer-paths":{
"./monolog/": ["monolog/monolog"]
}
by adding the installer-paths part, you are telling composer to install the monolog package inside the monolog folder in your root directory.
As an added new feature, we have added more flexibility in defining your download directory same like the composer/installers, in other words you can use variables like {$vendor} and {$name} in your installer-path section:
"extra": {
"installer-paths": {
"./customlibs/{$vendor}/db/{$name}": ["doctrine/orm"]
}
}
the above will manage to install the doctrine/orm package in the root folder of your project, under customlibs.
Note
Composer type: project is not supported in this installer, as packages with type project only make sense to be used with application shells like symfony/framework-standard-edition, to be required by another package.
My project relies on ZF and on a JS library. I wanted to be able to deploy the ZF library to the normal location (vendor/zendframework/zendframework1) but then deploy my JS library to somewhere else (public/my-vendor/my-library). Is there anyway to do this?
Composer is meant to manage your PHP dependencies, not JS.
Also, it only supports one vendor folder.
You might follow the way Symfony bundles use:
install everything in vendor
link (or copy) public assets to a public directory as part of your deployment process
In my opinion it's safer than installing something in a public folder (as long as you copy/link public part of a library only).
I came across the symlink idea but I wanted to automate this instead of manually creating the symlinks. I was going to create a composer script to create the symlink. I then found that symlinks on Windows and *nix need to be created in different ways which made this solution get messier by the second. I found that in the composer docs they talk about this same type of issue on the custom installers page and say that to solve this to create your own custom installer.
Relavent docs section: http://getcomposer.org/doc/articles/custom-installers.md
My custom installer: https://github.com/ddelrio1986/zf1-public-asset-installer
I have implemented this composer plugin to install packages into user (custom) defined folders you can just include it in your composer.json, follow the example and tell me if you have more questions :)
https://github.com/mnsami/composer-custom-directory-installer
composer-custom-directory-installer
A composer plugin, to install differenty types of composer packages in custom directories outside the default composer default installation path which is in the vendor folder.
This is not another composer-installer library for supporting non-composer package types i.e. application .. etc. This is only to add the flexability of installing composer packages outside the vendor folder. This package only supports composer package types,
https://getcomposer.org/doc/04-schema.md#type
The type of the package. It defaults to library.
Package types are used for custom installation logic. If you have a package that needs some special logic, you can define a custom type. This could be a symfony-bundle, a wordpress-plugin or a typo3-module. These types will all be specific to certain projects, and they will need to provide an installer capable of installing packages of that type.
How to use
Include the composer plugin into your composer.json require section::
"require":{
"php": ">=5.3",
"mnsami/composer-custom-directory-installer": "1.1.*",
"monolog/monolog": "*"
}
In the extra section define the custom directory you want to the package to be installed in::
"extra":{
"installer-paths":{
"./monolog/": ["monolog/monolog"]
}
by adding the installer-paths part, you are telling composer to install the monolog package inside the monolog folder in your root directory.
As an added new feature, we have added more flexibility in defining your download directory same like the composer/installers, in other words you can use variables like {$vendor} and {$name} in your installer-path section:
"extra": {
"installer-paths": {
"./customlibs/{$vendor}/db/{$name}": ["doctrine/orm"]
}
}
the above will manage to install the doctrine/orm package in the root folder of your project, under customlibs.
Note
Composer type: project is not supported in this installer, as packages with type project only make sense to be used with application shells like symfony/framework-standard-edition, to be required by another package.
By default, Composer reads composer.json schema. But, it can also use a different file. For instance, you can have zendframework.json and my-library.json.
In the zendframework.json, you can define:
"config": {
"vendor-dir": "zendframework/vendor"
},
In the my-library.json, you can define:
"config": {
"vendor-dir": "my-library/vendor"
},
Finally, you can update the libraries in this way:
COMPOSER=zendframework.json composer update
COMPOSER=my-library.json composer update
This is a simple idea. The benefit is that you solve the issue without third-party tools.