I'm just trying to grasp the concepts of dependency managers and GIT systems, so it's very possible I'm missing something very basic.
I use ROOTS/BEDROCK project as a base of my Wordpress projects. It allows to use Composer with Wordpress (by adding Wordpress itself as a dependency) and various other awesome features. It is installable as a Packagist package by command composer create-project roots/bedrock.
However to make it fit with my Wordpress framework, I needed to do a light customization of the project. So I forked it and submited the fork to http://packagist.org with entirely new composer.json file.
What I do not understand is why composer after command composer create-project myaccount/forked_bedrock installs original repository and not my fork.
TL;DR
Is it possible to submit a forked GitHub repository to Packagist and use the fork (not the original repo) by create-project command?
Thanks in advance!
It seems that the problem lied within Composer cache - after I've cleared it, Composer loaded the forked GitHub repository (not the original).
If Composer caches so "heavily", it would be nice if there was some option to clear/flush the cache, but apparently there is nothing built-in ...
in my case was that i had to change the name of the package in the composer.json, changing the "name" propierty f
Related
There is a github repository that is no longer actively maintained. I want to use the code and move it into my project's components but that is tedious and not sure if that is the best approach.
I just want to bump the version of draftjs used by the repository.
Here is the repo and it uses draft js version 0.10.0
https://github.com/brijeshb42/medium-draft
My local project uses draft js version 0.11.7
This causes errors and incompatibility issues.
What is the best approach when a repository uses an outdated version of a repository used by local project?
Before forking and publishing to npm your own version of that dependencies, you might consider using the package/patch-package
Patches created by patch-package are automatically and gracefully applied when you use npm(>=5) or yarn.
No more waiting around for pull requests to be merged and published. No more forking repos just to fix that one tiny thing preventing your app from working.
# fix a bug in one of your dependencies
vim node_modules/some-package/brokenFile.js
# run patch-package to create a .patch file
npx patch-package some-package
# commit the patch file to share the fix with your team
git add patches/some-package+3.14.15.patch
git commit -m "fix brokenFile.js in some-package"
In your case, you would be patching the brijeshb42/medium-draft/package.json file.
I have a main repository which is core router for mine system modules.
So every module is a standalone repository also.
How can I make that pushing to main repository will fire event to push the updated code to standalone repository?
Just as like https://github.com/Sylius/Sylius - they have main repository (this link) in which they collect pull-requests and standalone repositories like https://github.com/Sylius/SyliusTaxonomyBundle which exists in src/Sylius/Bundle/TaxonomyBundle
Don't they manually push the updates to standalone repos? Or some kind of github hooks? git subtree?
And why they do have the "replace" section in composer.json? How does this works? I didn't get an idea from official documentation :((
Sylius (and Symfony) create separate repositories for their components and bundle so that they can be used independently with composer. They only work in a single repository and use subtree to split the components and bundle into read only repositories.
I don't believe they are technically read-only, this is just an easier workflow than having to pull changes from the subrepo's in every time.
They probably use something like Git Subsplit GitHub WebHook to automatically update the subrepo's.
Using they replace key means that Sylius/Sylius contains Sylius/SyliusCartBundle in its self.
So when using a project which uses Sylius/Sylius and Sylius/SyliusCartBundle, Composer knows not to download Sylius/SyliusCartBundle because it is already provided by Sylius/Sylius.
A while back I had to use a jQuery plugin in my project. I needed some different functionality,
so I rewrote the plugin and a few days back I published a fork on github. I wanted to add the
package to the bower repository.
The forked repository
I added a bower.json file to the repository and registered the package with the usual "bower register" command.
The problem is, when I try to install my package, bower installs the original script and not the fork.
What I already tried:
At first I thought it's because I didn't make a release, so I fixed that part. But It didn't help.
I also tried to change the version number to the version number of the original script with no luck.
So maybe the bower.json file I wrote was not well written, right? My next attempt was using Bower to
make a propper bower.json file for me using "bower init". No luck.
So what could I be doing wrong?
The GitHub help page defines a fork as a method to use someone else's project as a starting point for your own idea.
That was my intention since I rewrote the plugin to be oo oriented and added some functionality, but 80% of the code
used is still from the original plugin and it didn't feel right to just make a new repository. Should I instead make a new repository
and will registering my repo with Bower work then?
What is the usual approach if you did some medium to major changes to a repository? Do you fork it or publish a new repo?
Do you still make a pull request even if the changes are bigger?
This worked for me :
Fork the repository
Clone on your disk
Increment the version number in bower.json (ex. 2.0.1)
Commit and push
Create a new version tag higher than the forked repository. ex: git tag "2.0.1"
Push : git push --tag
bower install "https://github.com/myname/forkedrepo.git#2.0.1"
You don't need to create a new repository. A fork will work fine.
But you can't overload on someone else's registered package name with bower. It does look like you've changed the name from onepage-scroll to onepage-scroll-extended though.
If you want to figure out what Bower knows about your package:
Do: bower info onepage-scroll-extended
{
name: 'onepage-scroll-extended',
homepage: 'https://github.com/itd24/onepage-scroll-extended',
version: '1.1.1'
}
Available versions:
- 1.1.1
- 1.0.1
Here you can see that it does not have the full bower.json manifest information and the latest information that it has is for version 1.1.1 (not 1.1.3, your latest).
This is because you don't have a v1.1.3 tag in your repository's master branch. I can see a v1.1.1 and v1.2 tag, but no v1.1.3 tag. Create that tag and push it up to GitHub to enable you to bower install that new version.
You may also need to re-run the bower register command to tell it to pick up the latest manifest. This should be happening automatically (AFAIK). You don't include the bower register command that you ran, perhaps you used the wrong repo URL there. You should use something like:
bower register onepage-scroll-extended git#github.com:itd24/onepage-scroll-extended.git
I have a Laravel 4 project, and I would like to know which files should be ignored when using a version control software such as Git, Mercury or SVN?
The structure of my project looks like the following screen capture.
I'm pretty new to Composer so I'm not very clear about what goes to a repo what not. If someone can post their .gitignore file or their SVN ignore property, it could be handy.
For reference, that .gitignore file can be found here:
/bootstrap/compiled.php
/vendor
composer.phar
composer.lock # Remove this one after you create a project
.env.*.php
.env.php
.DS_Store
Thumbs.db
As noted in the below comment, you probably want to commit composer.lock in your project. Laravel ignores it by default so the authors of the laravel/laravel package don't accidently impose packages on you.
Your project should include the composer.lock file so you can install packages of stable versions (via composer install instead of composer update) properly in your production environments.
Note that the config file:
app/config/app.php
Has a cryptographic key in it that wouldn't be great to commit to a repository. Or, at least, the file needs to be overwritten in production.
You might also want to see the Laravel docs here and here. This discusses how to setup different Laravel configurations for different environments and protect sensitive information. All your .env.local.php type files should not be included in version control. Note that the .env.*.php and .env.php is added in the default Laravel .gitignore file. You can see it here
Laravel has posted their .gitignore on GitHub, which can be found here.
As of today, it looks like this:
/bootstrap/compiled.php
/vendor
composer.phar
composer.lock
.env.*.php
.env.php
.DS_Store
Thumbs.db
GitHub has a repository of suggested .gitignore files for almost all kinds of projects at: http://github.com/github/gitignore
Alternatively, you can search it for your project using this handy and extremely useful online tool: http://www.gitignore.io
What are the best practices for using one mercurial project in another? I've got a django app that I'm working on, but I'm also using mercurial to version control a website that uses that app. I've looked at mercurial subrepositories, but apparently this is considered a "feature of last resort". Is there a good way of doing what I want to do, or do I just have to copy the code from my app into my website repo when I want to update to a new version of my app?
In your specific case I like to let pip handle my django application dependencies: http://guide.python-distribute.org/pip.html#installing-from-a-vcs
We have in our "website" repo a requirements.txt and our deploy does a pip install --upgrade -r requirements.txt That pulls the latest from the repo and installes it into the application's virtual env. This gives nice flexibility and separation while leaving the package management up to pip. With those VCS urls in pip you can point to a specific tag or branch too if you want different sites using different revisions from the same underlying repo.
pip also has a -e /path/to/file mode for pointing to an "editable" clone that's outside the website repo, which would work too, but I've not tried it.
That said, if you think subrepos fit your workflow better by all means use them. They work just fine, but people often get hung up on the workflow constraints ("What do you mean I can't commit my parent repo w/o also committing in the subrepo?!")