Is there a way to clean unused dependencies and composer dev requires to reduce a Laravel project, because it's so heavy (43,3 Mb) and it's a small project. Btw, I'm using some dev helpers like Debugbar and IDEHelpers which are not used for deployment...
Is there a way to make a deployment version of my project in other folder
The recommended way to deploy your app is without the vendor directory. I'm going to assume that you're using git for your project. First, put the following in your .gitignore.
/vendor/
Now remove the vendor directory from your repository
git rm -r --cached vendor
git commit -m 'Removed vendor directory'
Now you have a two step deployment:
Update the app using git pull or however you usually deploy.
Run composer install --no-dev --optimize-autoloader. This will generate your vendor directory omitting any development only dependencies.
In order to take advantage of the --no-dev flag, you need to put your development dependencies in the require-dev section in your composer.json. For example:
"require-dev": {
"phpunit/phpunit": "~4.3"
}
Now PHPUnit will be required for development, but not when the --no-dev flag is specified.
Maybe I'm misunderstanding your question but when you deploy a project, you shouldn't be deploying the laravel app with it (/vendor/). You should run composer install and it will pull in all the dependencies. In your composer.json file you can also choose which dependencies are for dev environments only similar to the require-dev section found here: https://gist.github.com/philsturgeon/5976359
Related
When creating sites using a framework like Silverstripe I often want to use helper modules like gridfieldextensions and lumberjack.
I therefore use composer require to add the dependencies.
However when I follow my regular development work flow and use git add -A to add the module to the repo rather than the code being added to the repo I get a reference to it.
This causes problems when I then try to clone the site elsewhere (using Jenkins or another developer). The git clone or git pull leaves an empty directory.
I solve this by deleting the .git dir of the module and adding all the files.
Is there a better way to do this? Is using git submodule an option?
Somewhere i found a good .gitignore file that ignores everything and i have to tell it to include the custom modules for my project. It's like:
# ignore everything...
/*
# ...but
!/.htaccess
!/.gitignore
!/composer.json
!/composer.lock
!/Capfile
!/Gemfile
!/favicon.ico
!/touch-icon-*
!/mysite
!/some-module
#...other modules
# theme stuff
!/themes/
**/.sass-cache
**/node_modules
!**/node_modules/_manifest_exclude
#no assets in general, but /assets/.htaccess
!/assets
/assets/*
!assets/.htaccess
As FinBoWa already said you need the composer.json and composer.lock file in your project and running
composer install
on another machine it'll install the packages in the versions saved in the composer.lock file on that machine
composer install --no-dev
will only install the "normal" requirements, no dev-requirements like phpunit or other stuff you only need for developing or testing but not live
composer install --no-dev -o
will also optimize (-o) the auto loader, so it'll be a bit faster.
composer update
will update your packages, which might have funny side effects and break your site. So use it carefully and test afterwards.
composer update silverstripe/framework
will just update that package and finally
composer update silverstripe/*
will update all packages by the vendor silverstripe (e.g. framework and cms package)
See also:
gitignore documentation
composer documentation
I have a Neos project, consisting of a Site providing the main composer container. composer.json requires a huge number of packages (whole neos/flow environment), including some packages we develop.
Our deployment setup consists of Jenkins, building the css/javascript for both the site and plugin packages (only within their specific gits) and finally triggering TYPO3 Surf, which actually calls composer install and then rsync's to the server.
Right now, each time we want some changes in our dev branch to be deployed to the testing environment, we have to manually cd to the main composer directory, do a
composer update vendor/package && git add composer.lock && git commit -m "update composer.lock"`.
Is there anyway to always use the newest version of our plugin package with composer? Perhaps excluding the requirement from composer.lock, or just changing it without installing the actual packages.
For a continuous deployment to a testing server you could just make jenkins do a composer update and with your packages set to dev/master in the composer.json.
I have a Yii 2 web application which uses Composer for its dependencies. How am I supposed to deploy this application at a production server without having to run composer? What I would like to be done is to zip the whole application directory at the development server, copy it to the production server, unzip it and have it deployed there without any action run by composer.
I found the solution. Run:
composer install --prefer-dist --no-dev --optimize-autoloader
at the development system and to then copy the whole directory to the production server.
From the documentation:
--prefer-dist: Reverse of --prefer-source, Composer will install from dist if possible. This can speed up installs substantially on
build servers and other use cases where you typically do not run
updates of the vendors. It is also a way to circumvent problems with
git if you do not have a proper setup.
--no-dev: Skip installing packages listed in require-dev. The autoloader generation skips the autoload-dev rules.
--optimize-autoloader (-o): Convert PSR-0/4 autoloading to classmap to get a faster autoloader. This is recommended especially
for production, but can take a bit of time to run so it is currently
not done by default.
I'm using Composer for a small project. I've pushed composer.json and composer.lock to Git, and put the vendor/ folder into .gitignore, so I can install the dependencies at the server on deploy time.
Can I push composer.phar to the Git repo or should I install a new copy for the server? Not sure if the installation process is machine-dependant.
It's a lot easier to install composer.phar manually on each server where you need it, as it will prompt to be updated every 30 days, and you don't want to be forever updating the content of your repo for a composer update.
Composer is a tool to help you with your deployments, so it should not be a part of your deployments
I personally store composer.phar in git for some PHP projects, usually in the project root directory.
This has the advantage that you can easily enforce the same composer version across multiple team members / computers, which can reduce the differences in composer.lock files, especially after running composer update. This may not be very standard, but I often document this in the project README.
I want to use the autoloader generated by composer for my unit tests to load classes automatically.
Now I don't know if I should commit my vendor directory to my git repo. A pro is that everyone who clones my repo immediately can run the phpUnit tests. A con is that I ship a lot of proprietary code with my repo.
Should I insist that the user who clones my repo has to run composer install first and therefor has to have composer "installed"?
Is it a solution to don't commit vendor directory into my git repo but pack it into a release branch so that my application runs out of the box?
The official recommendation is to ignore vendor/:
Tip: If you are using git for your project, you probably want to add vendor into your .gitignore. You really don't want to add all of that code to your repository.
Make sure to include both your composer.json and composer.lock files, though.