I am trying to move away from git submodules for the development in my team. The most important reason for this is that when a team member commits changes in a submodule, but forgets to push to origin, but does push the reference to this new commit in the "root" project, origin is broken, and the other developers get the reference is not a tree error. This can be problematic if the developer in question pushed before going home, and that reference that is not a tree points to a commit on the developers laptop, which is in his bag, in a train somewhere.
I am trying to replace git submodules with composer. My reasoning is that if git doesn't know about my dependencies, these dependencies can't break the repo. I know how to add packages from packagist, and I also managed to add our own git repositories to composer, mainly with the help from this blog post.
The problem, and the last piece of the puzzle, is that our dependencies are git repositories that we are actively working on. If I push an update to one of our dependencies, I would like the local copies of the developers to update to this latest version when they do a composer update. The closest I got is to create a tag for each change to a dependency, and then update my composer.json with the id of this new tag.
What I would like to know, is if there is a way to have composer always check out the latest commit of a certain branch, or, if this is not possible, to always get the latest tag when I do a composer update. I don't really mind the tagging, I just don't want to keep updating composer.json during development.
The composer file I have for testing:
{
"config": {
"vendor-dir": "app/vendor"
},
"repositories":
[
{
"type": "package",
"package": {
"name": "wkjagt/seagull",
"version": "1.0",
"source": {
"url": "git#github.com:wkjagt/Seagull.git",
"type": "git",
"reference": "master"
}
}
}
],
"require": {
"wkjagt/seagull": "1.0.*"
}
}
I was expecting the 1.0.* to take the latest tag starting with 1.0, but once composer already has 1.0.1, it won't get 1.0.2 if I create it. Any help with this would be very much appreciated.
If you won't have to specify each version separately in your repositories section, you'll need to add a composer.json file to wkjagt/Seagull and include the package like this:
{
"type": "vcs",
"url": "https://github.com/wkjagt/Seagull"
},
Composer can then read through your tags and treat them as versions. If you always want the get the latest version require your package with the dev flag:
"require": {
"wkjagt/seagull": "#dev"
}
Related
I'm trying to use composer to automatically clone a git repository from github that isn't in packagist but it's not working and I can't figure out what am I doing wrong.
I think I have to include it among "repositories" like so:
"repositories": [
{
"url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
"type": "git"
}
],
and then probably list it in "require" section. It should be similar to this example but it doesn't work. It just gives this error:
Your requirements could not be resolved to an installable set of packages.
Have anyone tried to do something like this already?
That package in fact is available through packagist. You don't need a custom repository definition in this case. Just make sure you add a require (which is always needed) with a matching version constraint.
In general, if a package is available on packagist, do not add a VCS repo. It will just slow things down.
For packages that are not available via packagist, use a VCS (or git) repository, as shown in your question. When you do, make sure that:
The "repositories" field is specified in the root composer.json (it's a root-only field, repository definitions from required packages are ignored)
The repositories definition points to a valid VCS repo
If the type is "git" instead of "vcs" (as in your question), make sure it is in fact a git repo
You have a require for the package in question
The constraint in the require matches the versions provided by the VCS repo. You can use composer show <packagename> to find the available versions. In this case ~2.3 would be a good option.
The name in the require matches the name in the remote composer.json. In this case, it is gedmo/doctrine-extensions.
Here is a sample composer.json that installs the same package via a VCS repo:
{
"repositories": [
{
"url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
"type": "git"
}
],
"require": {
"gedmo/doctrine-extensions": "~2.3"
}
}
The VCS repo docs explain all of this quite well.
If there is a git (or other VCS) repository with a composer.json available, do not use a "package" repo. Package repos require you to provide all of the metadata in the definition and will completely ignore any composer.json present in the provided dist and source. They also have additional limitations, such as not allowing for proper updates in most cases.
Avoid package repos (see also the docs).
At the time of writing in 2013, this was one way to do it. Composer has added support for better ways: See #igorw 's answer
DO YOU HAVE A REPOSITORY?
Git, Mercurial and SVN is supported by Composer.
DO YOU HAVE WRITE ACCESS TO THE REPOSITORY?
Yes?
DOES THE REPOSITORY HAVE A composer.json FILE
If you have a repository you can write to: Add a composer.json file, or fix the existing one, and DON'T use the solution below.
Go to #igorw 's answer
ONLY USE THIS IF YOU DON'T HAVE A REPOSITORY
OR IF THE REPOSITORY DOES NOT HAVE A composer.json AND YOU CANNOT ADD IT
This will override everything that Composer may be able to read from the original repository's composer.json, including the dependencies of the package and the autoloading.
Using the package type will transfer the burden of correctly defining everything onto you. The easier way is to have a composer.json file in the repository, and just use it.
This solution really only is for the rare cases where you have an abandoned ZIP download that you cannot alter, or a repository you can only read, but it isn't maintained anymore.
"repositories": [
{
"type":"package",
"package": {
"name": "l3pp4rd/doctrine-extensions",
"version":"master",
"source": {
"url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
"type": "git",
"reference":"master"
}
}
}
],
"require": {
"l3pp4rd/doctrine-extensions": "master"
}
You can include git repository to composer.json like this:
"repositories": [
{
"type": "package",
"package": {
"name": "example-package-name", //give package name to anything, must be unique
"version": "1.0",
"source": {
"url": "https://github.com/example-package-name.git", //git url
"type": "git",
"reference": "master" //git branch-name
}
}
}],
"require" : {
"example-package-name": "1.0"
}
Just tell composer to use source if available:
composer update --prefer-source
Or:
composer install --prefer-source
Then you will get packages as cloned repositories instead of extracted tarballs, so you can make some changes and commit them back. Of course, assuming you have write/push permissions to the repository and Composer knows about project's repository.
Disclaimer: I think I may answered a little bit different question, but this was what I was looking for when I found this question, so I hope it will be useful to others as well.
If Composer does not know, where the project's repository is, or the project does not have proper composer.json, situation is a bit more complicated, but others answered such scenarios already.
I try to join the solutions mention here as there are some important points to it needed to list.
As mentioned in the #igorw's answer the URL to repository must be in that case specified in the composer.json file, however since in both cases the composer.json must exist (unlike the 2nd way #Mike Graf) publishing it on the Packagist is not that much different (furthermore also Github currently provides packages services as npm packages), only difference instead of literally inputting the URL at the packagist interface once being signed up.
Moreover, it has a shortcoming that it cannot rely on an external library that uses this approach as recursive repository definitions do not work in Composer. Furthermore, due to it, there seems to be a "bug" upon it, since the recursive definition failed at the dependency, respecifying the repositories explicitly in the root does not seem to be enough but also all the dependencies from the packages would have to be respecified.
With a composer file (answered Oct 18 '12 at 15:13 igorw)
{
"repositories": [
{
"url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
"type": "git"
}
],
"require": {
"gedmo/doctrine-extensions": "~2.3"
}
}
Without a composer file (answered Jan 23 '13 at 17:28 Mike Graf)
"repositories": [
{
"type":"package",
"package": {
"name": "l3pp4rd/doctrine-extensions",
"version":"master",
"source": {
"url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
"type": "git",
"reference":"master"
}
}
}
],
"require": {
"l3pp4rd/doctrine-extensions": "master"
}
I was encountering the following error: The requested package my-foo/bar could not be found in any version, there may be a typo in the package name.
If you're forking another repo to make your own changes you will end up with a new repository.
E.g:
https://github.com/foo/bar.git
=>
https://github.com/my-foo/bar.git
The new url will need to go into your repositories section of your composer.json.
Remember if you want refer to your fork as my-foo/bar in your require section, you will have to rename the package in the composer.json file inside of your new repo.
{
"name": "foo/bar",
=>
{
"name": "my-foo/bar",
If you've just forked the easiest way to do this is edit it right inside github.
In my case, I use Symfony2.3.x and the minimum-stability parameter is by default "stable" (which is good). I wanted to import a repo not in packagist but had the same issue "Your requirements could not be resolved to an installable set of packages.".
It appeared that the composer.json in the repo I tried to import use a minimum-stability "dev".
So to resolve this issue, don't forget to verify the minimum-stability. I solved it by requiring a dev-master version instead of master as stated in this post.
If you want to use a composer.json from GitHub you would look at this example (under the VCS section).
The package section is for packages that do not have the composer.json. However, you didn't follow that example as well or it would also have worked. Do read what it says about package repositories:
Basically, you define the same information that is included in the composer repository's packages.json, but only for a single package. Again, the minimum required fields are name, version, and either of dist or source.
https://stackoverflow.com/a/14485706/11716408
{
"repositories": [
{
"type":"package",
"package": {
"name": "tiagof2/materializecss-laravel-pagination",
"version":"v1.0.3",
"source": {
"url": "https://github.com/tiagofrancafernandes/materializecss-laravel-pagination.git",
"type": "git",
"reference":"v1.0.3"
}
}
}
],
"require": {
"tiagof2/materializecss-laravel-pagination": "v1.0.3"
},
}
composer update
I have tried to publish a project with composer. The project resides at github, and are published through packagist.org.
But when I try to create my project with composer it fails with this error message:
"Could not find package madskullcreations/simplicity with stability
stable."
I use the following command:
composer create-project madskullcreations/simplicity
The composer.json contains this:
{
"name": "madskullcreations/simplicity",
"description": "Website made simple!",
"homepage": "https://madskullcreations.com",
"type": "project",
"license": "GPL-3.0-or-later",
"minimum-stability": "dev",
"require": {
"php": ">=5.6",
"cakephp/cakephp": "3.5.*"
}
}
My repository contains just one file for testing. What is wrong? I tried to remove the dependencies, the entire "require"-block, but no real change...
Beginner as I am, I don't even know where I would define the packages "stability", can't find anything at github or at packagist.
Please help me get this started!
Working solution:
I eventually got it working with the help from Flying, see his answer further down. Since I think it is a wee bit complicated to get composer up'n working, I try to put the steps I did to get it working here:
Create a repository at github.
Create a composer.json with your depencencies. Check it in.
Release it. There are a "Releases" link somewhere, use it and give the release a name.
Now, to skip the packagist.org step during your testing, follow these steps. It is not good style to publish a non-working solution (like I did) on packagist.org, and it's no fun at all to do all the steps necessary ten times over.
Create a local folder somewhere, and create a new composer.json file there.
Put something like this in it:
{
"require": {
"madskullcreations/simplicity":"dev-master#dev"
},
"repositories": [
{
"type": "vcs",
"url": "https://github.com/madskullcreations/simplicity"
}
]
}
Run the following command in your new folder:
composer create-project
It should now download and install your project.
And, read the error messages given by composer and make sure you understand them. They are useful. My headache was a missing PHP-extension (intl) and that I assumed it was using php version 7.1, while it actually listened to my requirement in the composer.json file, and used v5.6. (I have several php-versions installed in iis, but my fuzzy head did not consider that.)
Packages stability requirement is defined into minimum-stability setting of composer.json of your project, not a composer.json of the external package.
Your madskullcreations/simplicity package have no releases defined so the only branch that is available in it - is dev-master "release" (it can be seen at the right side of package page on Packagist). This "release" have "dev" stability level.
Because of above if you're requiring this package into your project without either setting minimum-stability: dev or without specifying stability requirement for a package as
"require": {
"madskullcreations/simplicity":"dev-master#dev"
}
(notice #dev into version requirement) it is correct behavior of Composer to complain about lack of compatible releases.
Also it is generally bad practice to publish your test packages into public registry like Packagist. Instead you should use direct repository specification into your composer.json as explained here. In your case it will be:
"repositories": [
{
"type": "vcs",
"url": "https://github.com/madskullcreations/simplicity"
}
]
After specifying direct repository reference - it will be safe to remove your test package from Packagist unless you're really want to share it with open source community.
I had to modify a vendor package (avatarguru/mustache-l5), which was not compatible with the latest version of Laravel 5 (dev) framework. But now when I do composer status in the project's root directory, it shows No local changes. I also tried to modify some other packages - same thing...
How do I commit that changes to composer.lock, so that other developers will not have to fix same packages again?
You should fork the package, create a custom repo with your changes - then include that in your composer.json.
{
"repositories": [ {
"type": "vcs",
"url": "https://github.com/YourGithubUsername/PackageName"
}
}],
"require": {
"laravel/framework": "4.0.*",
"OriginalVendor/PackageName": "1.0.*"
},
}
That way you can pull your custom changes in anytime, without having to commit it to your specific project.
You can read more about forking and loading packages here: https://getcomposer.org/doc/05-repositories.md#vcs
I'm trying to load a library I have hosted on BitBucket using composer as explained both in the official documentation and here, but keep receiving the following error:
[Composer\Repository\InvalidRepositoryException]
No valid composer.json was found in any branch or tag of [repository URL], could not load a package from it.
Here is my project composer.json:
{
"name": "Project name",
"require": {
"my-vendor/my-package": "dev-master"
},
"repositories": [
{
"type": "vcs",
"url": [repository URL]
}
]
}
And here is the composer.json in my remote repository (that apparently can't be found):
{
"name": "my-vendor/my-package",
"version": "0.3",
"autoload": {
"psr-0": {
"NS_": "src"
}
}
}
I should mention that both composer.json files are in the root directory as they should be.
Some other things to note:
I've also tried the "non-composer package" approach, whereby I specify the package information in my project composer.json, and omit the composer.json from my remote repository, as outlined in the documentation. This successfully clones the master branch but then results in the following error:
[RuntimeException]
Failed to execute git checkout "master" && git reset --hard "master"
fatal: Not a git repository (or any of the parent directories): .git
However, the package is downloaded to /vendor as expected, so I'm not sure why it's trying to checkout master again.
This is not the way I wish to solve this problem (as I'd rather make use of a composer.json in the remote repository), but it might help identify an issue elsewhere.
Thanks for any help.
EDIT
I've managed to get it working by referencing a package.json over HTTP:
"repositories": [
{
"type": "composer",
"url": "http://localhost/packages.json"
}
]
The packages.json looks like:
{
"packages": {
"vendor/my-package": {
"dev-master": {
"name": "vendor/my-package",
"version": "dev-master",
"source": {
"url": [repository URL],
"type": "git",
"reference": "master"
}
}
}
}
}
Is this the only way to get this working? It seems a bit overkill to host my own packages.json file if I'm only going to be using one or two in-house packages.
Regardless, this is giving me the same Git error as I mentioned previously.
EDIT 2
Forcing an error (invalid SSH passphrase) gives this:
[RuntimeException]
Failed to execute git clone "[repository URL]" "C:\workspace\DFv3\vendor\vendor/my-package" && cd /D "C:\workspace\DFv3\vendor\vendor/my-package" && git remote add composer "[repository URL]" && git fetch composer
So I can clearly see what it's doing here. However, it seems after this command runs it cds into the .git directory and tries running:
git checkout "master" && git reset --hard "master"
Presumably to get rid of the composer instance it pulled. However, it's running this in the wrong directory and I can't figure out why..
I know this is a bit old, but for some that might encounter this issue, this is how it works for me.
Clear the composer cache.
composer clearcache
Rerun the satis build script.
You must not include a version specification in your library's composer.json if it is actually managed by a supported source control system. Currently you are saying that your master branch IS version 0.3 (which is a stable version), but you are trying to include "dev-master" (which is an unstable version). Composer might get confused if that software really is "dev-master" or "version 0.3".
If you actually are developing new releases for the 0.3.x series in your master branch, you should define a branch alias instead. Add this to your current development branch for versions 0.3.x:
"extra": {
"branch-alias": {
"dev-master": "0.3.x-dev"
}
}
If you want to move on to version 0.4 or 1.0, you'd branch at the "last" state of the 0.3 series with a branch named "0.3.x" and then update the composer.json in the master branch to point dev-master to a new alias (like "dev-master": "0.4.x-dev"). You could also name your old 0.3 branch anyway you like and then add an alias for THAT branch.
Doing this will enable you to require the latest development version of 0.3.x like this:
"require": {
"my-vendor/my-package": "0.3.*#dev"
}
This will pull the latest 0.3 version - which currently would be the latest commit in the master branch because of the defined alias.
The way you are currently set up forces you to explicitly include version 0.3, which is a moving target without making that fact explicitly known.
Giving an explicit version tag should only be done if there is no version control system available that is able to give Composer the version number, i.e. there are no tags available, or the tags do not comply with Composer's requirement for version numbers. Since you seem to be in control of that vcs, it probably is a good idea to make the tags conform to Composers standard instead of making it troublesome to release a new version.
After you fixed this, I do expect your installation to NOT require that package.json file anymore, because that file now repairs the trouble you created with that version declaration. You'd then also not need that composer reference anymore, but can revert back to mentioning the original repository like you did.
If you feel you are using too many private repositories which are all requiring more private repositories, and are sick of mentioning them all in a long list, you could think about using Satis to create such a list of found packages instead of manually creating them.
I had the same error, after deleting folders from vcs everything works fine
sudo rm -R ~/.composer/cache/vcs/*
On Windows (as #Serbu suggested):
Clearing the vcs, repo and files directories under
C:\Users\Me\AppData\Local\Composer\
I've managed to get it working by referencing a package.json over HTTP:
"repositories": [
{
"type": "composer",
"url": "http://localhost/packages.json"
}
]
so the packages.json file looks like:
{
"packages": {
"vendor/my-package": {
"dev-master": {
"name": "vendor/my-package",
"version": "dev-master",
"source": {
"url": [repository URL],
"type": "git",
"reference": "master"
}
}
}
}
}
Also, its seems an autorun registry entry I had for command prompt was interfering with composer running.
See: Requiring a private git Bitbucket repository fails to find valid composer.json.
While this might be considered necromancy, I stumbled across this question yesterday while having an issue just like this (although in my case I was running an Ubuntu Docker container and not Windows as the OP was) and thought I would leave my thoughts and resolution here should anyone else stumble across this.
The Ubuntu repo version of Composer is currently sitting at 1.6.x (at the time of writing, Composer is up to 1.9.1 I believe) and I was getting different errors depending on if I ran composer install with different levels of logging. Without logging, it moaned that it couldn't find a valid composer.json. With logging, it moaned that it couldn't access the repo (despite scanning the tags).
The solution for me was to globally install the latest version of Composer as the Ubuntu repo version was using outdated BitBucket API calls (v1 is deprecated). Once I had updated to a newer version of Composer, the install ran perfectly.
So check your Composer version and install an updated version if possible (a local/project install should work too).
I've just updated composer.json to last version and the problem gone away.
I'm trying to use composer to automatically clone a git repository from github that isn't in packagist but it's not working and I can't figure out what am I doing wrong.
I think I have to include it among "repositories" like so:
"repositories": [
{
"url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
"type": "git"
}
],
and then probably list it in "require" section. It should be similar to this example but it doesn't work. It just gives this error:
Your requirements could not be resolved to an installable set of packages.
Have anyone tried to do something like this already?
That package in fact is available through packagist. You don't need a custom repository definition in this case. Just make sure you add a require (which is always needed) with a matching version constraint.
In general, if a package is available on packagist, do not add a VCS repo. It will just slow things down.
For packages that are not available via packagist, use a VCS (or git) repository, as shown in your question. When you do, make sure that:
The "repositories" field is specified in the root composer.json (it's a root-only field, repository definitions from required packages are ignored)
The repositories definition points to a valid VCS repo
If the type is "git" instead of "vcs" (as in your question), make sure it is in fact a git repo
You have a require for the package in question
The constraint in the require matches the versions provided by the VCS repo. You can use composer show <packagename> to find the available versions. In this case ~2.3 would be a good option.
The name in the require matches the name in the remote composer.json. In this case, it is gedmo/doctrine-extensions.
Here is a sample composer.json that installs the same package via a VCS repo:
{
"repositories": [
{
"url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
"type": "git"
}
],
"require": {
"gedmo/doctrine-extensions": "~2.3"
}
}
The VCS repo docs explain all of this quite well.
If there is a git (or other VCS) repository with a composer.json available, do not use a "package" repo. Package repos require you to provide all of the metadata in the definition and will completely ignore any composer.json present in the provided dist and source. They also have additional limitations, such as not allowing for proper updates in most cases.
Avoid package repos (see also the docs).
At the time of writing in 2013, this was one way to do it. Composer has added support for better ways: See #igorw 's answer
DO YOU HAVE A REPOSITORY?
Git, Mercurial and SVN is supported by Composer.
DO YOU HAVE WRITE ACCESS TO THE REPOSITORY?
Yes?
DOES THE REPOSITORY HAVE A composer.json FILE
If you have a repository you can write to: Add a composer.json file, or fix the existing one, and DON'T use the solution below.
Go to #igorw 's answer
ONLY USE THIS IF YOU DON'T HAVE A REPOSITORY
OR IF THE REPOSITORY DOES NOT HAVE A composer.json AND YOU CANNOT ADD IT
This will override everything that Composer may be able to read from the original repository's composer.json, including the dependencies of the package and the autoloading.
Using the package type will transfer the burden of correctly defining everything onto you. The easier way is to have a composer.json file in the repository, and just use it.
This solution really only is for the rare cases where you have an abandoned ZIP download that you cannot alter, or a repository you can only read, but it isn't maintained anymore.
"repositories": [
{
"type":"package",
"package": {
"name": "l3pp4rd/doctrine-extensions",
"version":"master",
"source": {
"url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
"type": "git",
"reference":"master"
}
}
}
],
"require": {
"l3pp4rd/doctrine-extensions": "master"
}
You can include git repository to composer.json like this:
"repositories": [
{
"type": "package",
"package": {
"name": "example-package-name", //give package name to anything, must be unique
"version": "1.0",
"source": {
"url": "https://github.com/example-package-name.git", //git url
"type": "git",
"reference": "master" //git branch-name
}
}
}],
"require" : {
"example-package-name": "1.0"
}
Just tell composer to use source if available:
composer update --prefer-source
Or:
composer install --prefer-source
Then you will get packages as cloned repositories instead of extracted tarballs, so you can make some changes and commit them back. Of course, assuming you have write/push permissions to the repository and Composer knows about project's repository.
Disclaimer: I think I may answered a little bit different question, but this was what I was looking for when I found this question, so I hope it will be useful to others as well.
If Composer does not know, where the project's repository is, or the project does not have proper composer.json, situation is a bit more complicated, but others answered such scenarios already.
I try to join the solutions mention here as there are some important points to it needed to list.
As mentioned in the #igorw's answer the URL to repository must be in that case specified in the composer.json file, however since in both cases the composer.json must exist (unlike the 2nd way #Mike Graf) publishing it on the Packagist is not that much different (furthermore also Github currently provides packages services as npm packages), only difference instead of literally inputting the URL at the packagist interface once being signed up.
Moreover, it has a shortcoming that it cannot rely on an external library that uses this approach as recursive repository definitions do not work in Composer. Furthermore, due to it, there seems to be a "bug" upon it, since the recursive definition failed at the dependency, respecifying the repositories explicitly in the root does not seem to be enough but also all the dependencies from the packages would have to be respecified.
With a composer file (answered Oct 18 '12 at 15:13 igorw)
{
"repositories": [
{
"url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
"type": "git"
}
],
"require": {
"gedmo/doctrine-extensions": "~2.3"
}
}
Without a composer file (answered Jan 23 '13 at 17:28 Mike Graf)
"repositories": [
{
"type":"package",
"package": {
"name": "l3pp4rd/doctrine-extensions",
"version":"master",
"source": {
"url": "https://github.com/l3pp4rd/DoctrineExtensions.git",
"type": "git",
"reference":"master"
}
}
}
],
"require": {
"l3pp4rd/doctrine-extensions": "master"
}
I was encountering the following error: The requested package my-foo/bar could not be found in any version, there may be a typo in the package name.
If you're forking another repo to make your own changes you will end up with a new repository.
E.g:
https://github.com/foo/bar.git
=>
https://github.com/my-foo/bar.git
The new url will need to go into your repositories section of your composer.json.
Remember if you want refer to your fork as my-foo/bar in your require section, you will have to rename the package in the composer.json file inside of your new repo.
{
"name": "foo/bar",
=>
{
"name": "my-foo/bar",
If you've just forked the easiest way to do this is edit it right inside github.
In my case, I use Symfony2.3.x and the minimum-stability parameter is by default "stable" (which is good). I wanted to import a repo not in packagist but had the same issue "Your requirements could not be resolved to an installable set of packages.".
It appeared that the composer.json in the repo I tried to import use a minimum-stability "dev".
So to resolve this issue, don't forget to verify the minimum-stability. I solved it by requiring a dev-master version instead of master as stated in this post.
If you want to use a composer.json from GitHub you would look at this example (under the VCS section).
The package section is for packages that do not have the composer.json. However, you didn't follow that example as well or it would also have worked. Do read what it says about package repositories:
Basically, you define the same information that is included in the composer repository's packages.json, but only for a single package. Again, the minimum required fields are name, version, and either of dist or source.
https://stackoverflow.com/a/14485706/11716408
{
"repositories": [
{
"type":"package",
"package": {
"name": "tiagof2/materializecss-laravel-pagination",
"version":"v1.0.3",
"source": {
"url": "https://github.com/tiagofrancafernandes/materializecss-laravel-pagination.git",
"type": "git",
"reference":"v1.0.3"
}
}
}
],
"require": {
"tiagof2/materializecss-laravel-pagination": "v1.0.3"
},
}
composer update