I am working on a project with multiple local git repositories that tie together into a single app. Pretty much like Symfony has different components our app is split up similarly.
My question is, what is the proper way to link to these packages?
I know I can do something like this:
"repositories": [
{ "type": "path", "url": "../another-component" },
{ "type": "path", "url": "../yet-another-component" }
]
This still forces me to do composer install to pull in the packages though. It clones the local git repository that I am using for development whenever I run composer install.
Obviously I do not want to do this every single time I adjust a component that makes up a part of my main app to pull in any changes I have done to repositories that make up my main app repository.
Is there a better way to keep development repositories in sync with each other? Or can I tweak this to get what I want?
I am guessing a lot of developers run into this problem so there must be a well thought out solution for this?
Cheers.
Edit
I have also seen this article which goes over the same concept:
http://tech.vg.no/2014/11/25/using-local-packages-as-composer-dependencies/#comment-522050
The problem is that everytime you make changes to one of the repositories that make up your app you have to run: composer update which is a hassle. I am really looking for a way to just keep them properly in sync.
The above solution works fine, I had to delete my lockfile and clear the composer cache though. Instead of cloning a repository composer will make a symlink and your repositories will be kept in sync.
It might not be advisable to delete your lockfile so if anyone has a better suggestion please post a comment.
Related
My team has recently put together a Laravel codebase that works great for multiple websites. Currently we are running them as an app that installs on a centOS7 profile.
Whenever a new site is required, we fire up a profile, and the code gets cloned in. The codebase depends heavily on packages (custom laravel packages). Currently every site pulls in all of the packages that we have developed. Currently the differences are 1) The .env file. and 2) The theme config files (which come from a package and I'll touch on later).
I want to be able to pull packages based on need, I don't want to pull in every package we've developed. My question is, is there a way around pulling in every package? I was thinking of removing the composer.json file from git and treating it like a config file? I also thought about generating the composer.json file.
Eventually we want to add CI/CD to the process and really automate this thing. I am really fighting to keep the codebase in one repository. Am I wrong? Should we split the codebase up, one repository per project that comes in? But then you have to consider that updates become a nightmare.
Currently, themes are pulled in as packages. Every site has all of the themes in the composer file. The app has admin users that can login and set a theme to active. Still, I'd like if it only pulled in the necessary themes resources.
Sorry if I rambled a bit, but I am wondering how to scale the application properly.
Thanks a bunch!
tldr; How can I run multiple websites using one codebase, while being able to specify different required custom packages?
I haven't actually tested this but you might be able to accomplish what you want by defining multiple composer.json files. Read more on defining other composer.json files
Then, in each composer.json file define a different vendor directory. Example:
{
"config": {
"vendor-dir": "plugins"
}
}
Next, on each install specify which composer.json file to install, From the docs:
By setting the COMPOSER env variable it is possible to set the filename of composer.json to something else.
Example from docs:
COMPOSER=composer-other.json php composer.phar install
Read more on specifying the environment.
Last but not least, you will have to bootstrap your website or application for the specific vendor directory:
require __DIR__.'/../custom-vendor-directory/autoload.php';
This can be customized in your application's index.php file. The original source.
We currently have Yii2 base project (we can say, like, project root from which we will create other projects). Right now there are several modules, models, controllers and viewers. Everything is fine here but how to deploy (and where) so that when we update base project, all child projects that were using our base project would be updated (best is through Composer with composer update).
For example, Kartik has its plugins/widgets and we can simply update through Composer with command like $ php composer.phar require kartik-v/yii2-grid "#dev".
So we want to have something similar, but not accessible publicly (so that random people couldn't access without some sort of email/username/password). This part is not as important as the first part because in this part we at least can use something like BitBucket. There aren't many possible solutions, most likely a few only, actually, but it's a challenge that we cannot solve right now.
I have tried StackExchange but it's not as popular StackOverflow, so I'm trying to give as much information as I can. Assuming I see this question, this question shouldn't be off-topic either. Thanks!
You could use your own private repository for keeping yii2 app template. To update all your projects use composer. Here's code example:
"repositories": [
{
"type":"package",
"package": {
"name": "repo-name/yii2template",
"version":"master",
"source": {
"url": "https://your-git-server.com/repo-name/yii2template.git",
"type": "git",
"reference":"master"
}
}
}
],
So when you make changes to your template, you just update composer for certain project and get those changes.
P.S. Another idea is Ansible. You can update child projects by this tool, but you have to write playbook manually for your needs.
If you need this template local only, you could use PhpStorm, it can make templates from project.
I am working on several projects but each one connects to a REST web service.
I've developed the first one using Laravel, and developed a few classes really useful to communicate with the web services.
I would like to start the second one, and of course, reuse the classes developed for the REST connection.
My problem is, my company wants me to use several git directories for the projects, and each one should be uploaded to a different springloops project.
Springloops is a bit like github, you can upload your code using git.
How would you proceed to avoid copy/paste and use the same laravel code but in different projects (and I guess, in different locations)?
I'm not sure I'm really clear, but don't hesitate to ask me for more information if you need to.
Thanks.
How about creating your own Composer package and store it in a separate (private) Git repo? As far as Composer is concerned it's just like any other package, you may want to check out this section of the docs:
Using private repositories
Exactly the same solution allows you to work with your private
repositories at GitHub and BitBucket:
{
"require": {
"vendor/my-private-repo": "dev-master"
},
"repositories": [
{
"type": "vcs",
"url": "git#bitbucket.org:vendor/my-private-repo.git"
}
]
}
The only requirement is the installation of SSH keys for a git client.
I've already spent a few hours searching for an answer to my question but still haven't found a suitable answer.
Basically, I've taken over a PHP project which uses composer to pull in third party libraries/dependencies. However, a lot of the dependencies are no longer managed and is possible that the author might remove them completely from github anytime.
I'm currently thinking that I should check in the whole vendor folder so even if the libraries are no longer available through composer, I will still have them with me.
Alternatively, I could fork those libraries repo and have composer to pull from my account instead. Is this acceptable?
I would really hope to get some advice on the best method to deal with this.
Thanks in advance!
Should i check in the whole vendor folder in, so even if the libraries are no longer available through composer, I will still have them with me?
My suggestion is to create a backup branch containing your application with all it's vendors. Just do a git checkout -b {VERSION}-backup, followed by composer install (which gets you the composer.lock and all dependencies into the defined vendor folder) and then a git push origin {VERSION}-backup.
This allows to rely on dynamic package management as long as the packages are available via Packagist and downloadable from their source (Github, etc.).
Now, in case, a dependency gets deleted and becomes un-available, you remove it from your composer.json and merge the code from the last {VERSION}-backup branch into the master branch. = You replaced a dynamic dependency with a static one from you backup.
By the way: ever thought about getting a security audit for your code?
This will not work, with dynamically pulled dependencies. Security audits are done for specific versions - for a static set of dependencies. Given this context, pushing in a complete app with all it's dependencies is common and a best-practice. But what do we have: Composer in the backend to install new themes and composer install --no-dev --optimize-autoload on the production box to "install" software. Modern times ;)
Could I fork those libraries repo and have composer to pull from my account instead. Is this acceptable?
Yes! And you might also ask the guys over at Packagist to remove no-longer maintained packs or get them replaced or aliased to a new personal fork.
It really depends on whether your project needs to be optimized for portability or not.
Although, it's better safe with a best-practice violation, than sorry with an unavailable dependency you have to spend time replacing and refactoring for ...
From her packagist - theoretically it is possible but unlikely.
From the practice the main problem with packages directly connected to CVS. But if it is live project you allays can find another copy of code to recover functional.
I have a git repo that contains a few small and related libraries. Since the platform I am working with lacks proper dependency management, dealing with many git repos is a hassle, hence my team decided to put these into one git repo. I'm now working on having our software being installable via Composer. It is however not clear to me how to register each component in this git repo, as I'm not even sure it is possible to have more then one composer.json file per repo. Is this possible? And if so, how?
"is it possible to have more then one composer.json file per repo."
No.
You can't register the components separately, they will be registered as one big dependency and you will have to import them all into other projects, rather than being able to pull them individually.
However you can register where each component lives in the directory structure so that the autoloader is able to load them correctly.
"autoload": {
"psr-0": {
"Intahwebz\\Component1": "src/Component1",
"Intahwebz\\Component2": "src/Intahwebz/Component2",
"Intahwebz": "src/"
}
}
After including the Composer generated autoloader, creating a new class of type Intahwebz\Component1\TestClass will find it in the correct directory.