For a project I'm working on I would like to create a 'Core' package containing multiple smaller packages, like laravel does with it's framework.
The folder structure would be something like this,
Package1: gybrus/core/src/Gybrus/Package1
Package2: gybrus/core/src/Gybrus/Package1
After doing some research I've noticed this could be achieved with composer if I'm not mistaken but this is also where it breaks for me.
Currently I have multiple composer.json files, but after running the 'php artisan dump-autoload' command the classes aren't added to the autoload files.
Therefore I'm wondering if the Laravel framework adds some extra magic to make this happen.
Thanks in advance!
This is my current setup, I've changed the package names for the sake of not advertising something ;)
The first composer file is in the 'core' folder next to the 'src' folder.
{
"name": "gybrus/core",
"description": "The Core",
"keywords": ["core"],
"authors": [
{
"name": "Kevin Dierkx",
"email": "email#email.com"
}
],
"require": {
"php": ">=5.3.0",
"laravel/framework": "4.0.x"
},
"replace": {
"gybrus/package1": "self.version"
},
"require-dev": {
"mockery/mockery": "dev-master",
"phpunit/phpunit": "3.7.*"
},
"autoload": {
"psr-0": {
"Gybrus": "src/"
}
},
"minimum-stability": "dev"
}
The second composer file is in the package1 folder:
{
"name": "gybrus/package1",
"authors": [
{
"name": "Gybrus",
"email": "email#email.com"
}
],
"require": {
"php": ">=5.3.0",
"illuminate/support": "4.0.x"
},
"autoload": {
"psr-0": {"Gybrus\\Package1": ""}
},
"target-dir": "Gybrus/Package1",
"minimum-stability": "dev"
}
Found the cause of my problem!
The first script tells composer that it should autoload the namespace 'Gybrus' starting in the 'src' folder, after some testing this works as intended.
Where the above setup breaks is the following line:
return Finder::create()->files()->in($workbench)->name('composer.json')->depth('< 3');
This tells the Finder to stop looking for composer.json files that are deeper than 2 folders.
Nothing weird so far.
Where is goes wrong is here, I symlinked the workbench packages into the workbench folder.
This causes the weird problem that the composer.json files are actually deeper than they should be, which in result stop the loading of the composer.json files and breaking the autoloading for these packages.
A quick fix would be to either don't symlink or run composer install from inside the package.
Related
In my composer.json I have written:
"autoload": {
"psr-4": {
"Pmochine\\MyOwnPackage\\": "src/"
},
"files": [
"src/helpers.php"
]
},
But somehow even after composer dump-autoload the functions are not loaded. I get "Call to undefined function". To create the package I used a package generator. Maybe it has something to do that it creates a symlink in the vendor folder?
Inside helpers I have written
<?php
if (! function_exists('myowntest')) {
function myowntest()
{
return 'test';
}
}
In the package service provider, try adding this:
// if 'src/helpers.php' does not work, try with 'helpers.php'
if (file_exists($file = app_path('src/helpers.php'))) {
require $file;
}
What you are doing is best practise and should work. I took the composer.json from barryvdh/laravel-debugbar as an example. https://github.com/barryvdh/laravel-debugbar/blob/master/composer.json
{
"name": "barryvdh/laravel-debugbar",
"description": "PHP Debugbar integration for Laravel",
"keywords": ["laravel", "debugbar", "profiler", "debug", "webprofiler"],
"license": "MIT",
"authors": [
{
"name": "Barry vd. Heuvel",
"email": "barryvdh#gmail.com"
}
],
"require": {
"php": ">=5.5.9",
"illuminate/support": "5.1.*|5.2.*|5.3.*|5.4.*|5.5.*",
"symfony/finder": "~2.7|~3.0",
"maximebf/debugbar": "~1.13.0"
},
"autoload": {
"psr-4": {
"Barryvdh\\Debugbar\\": "src/"
},
"files": [
"src/helpers.php"
]
}
}
My guess is that you are not requiring your own package the correct way in the main composer.json?
Just need to call in your main project
composer update you/your-package
Source
The only thing that has worked for me is to run composer remove <vendor>/<package> and require it back again. The files section was ignored otherwise.
This seems to happen while developing locally the package and making changes on the composer.json file.
With my clean Laravel 5.3 installation, I can run composer install to install the dependent packages.
Now, I've an internal package with its own composer.json, like below:
{
"name": "bar/foo",
"description": "A package for handling foo",
"licence": "MIT",
"authors": [
{
"name": "A. Foo",
"email": "a#foo.bar"
}],
"minimum-stability": "dev",
"require": {},
"autoload": {
"psr-4": {
"Foo\\Bar\\": "packages/foo/Bar/src"
}
}
}
So I prefer to autoload from the package itself, instead of autoloading from the main composer.json.
My questions:
Running composer dumpa from packages/foo/Bar doesn't take effect for autoloading. After Generating autoload files, Laravel doesn't know namespace Foo\Bar
Is there a way to run composer dumpa for all recursive composer.jsons?
You need to add the following section to your global composer.json
"repositories": [
{
"type": "path",
"url": "packages/*/*"
}
]
You also need to add the packages to the require object in composer.json
I am trying to install laravel Spark but getting a lot of errors no matter which method I try.
Upon adding "laravel/spark": "*#dev" in the composer.js file I am getting this error.
The requested package laravel/spark could not be found in any version,
there may be a typo in the package name.
Any clue what the issue is?
"require": {
"php": ">=5.5.9",
"laravel/framework": "5.2.",
"laravel/cashier": "~6.0",
"laravel/spark": "#dev"
}
Added to the composer.js file and ran composer update. Got the couldn't found error.
In your composer.json file, add the following to the require section (note that, compared to what you currently listed, this one has an asterisk * before the # symbol):
"laravel/spark": "*#dev"
Then add this in its own section (or update accordingly):
"repositories": [
{
"type": "path",
"url": "./spark",
"options": {
"symlink": false
}
}
],
The options portion is optional and you can leave it out
You can then run your composer install command. You can confirm that things are good by running composer validate, which will trigger a warning and it's fine to ignore that. You should also check the composer.lock file to make sure you have something similar to this in there:
{
"name": "laravel/spark",
"version": "dev-develop",
"dist": {
"type": "path",
"url": "./spark",
"reference": "072b0bf217fbbe5018fc062612bb1fb5566d94e1",
"shasum": null
},
"require": {
"erusev/parsedown": "~1.0",
"firebase/php-jwt": "~3.0|~4.0",
"guzzlehttp/guzzle": "~6.0",
"intervention/image": "^2.3",
"php": ">=5.5.9",
"ramsey/uuid": "^3.1"
},
"require-dev": {
"mockery/mockery": "0.9.*",
"mpociot/vat-calculator": "^1.6",
"phpunit/phpunit": "~5.0"
},
"type": "library",
"extra": {
"branch-alias": {
"dev-master": "4.0-dev"
}
},
"autoload": {
"psr-4": {
"Laravel\\Spark\\": "src/"
}
},
"license": [
"MIT"
],
"authors": [
{
"name": "Taylor Otwell",
"email": "taylorotwell#gmail.com"
}
],
"description": "Laravel Spark provides scaffolding for Laravel SaaS applications.",
"keywords": [
"billing",
"laravel",
"saas",
"scaffolding",
"stripe"
],
"transport-options": {
"symlink": false
}
},
Also, depending on your version and how you set things up, you'll have to check on the documentation because there's a few different ways to set this up:
https://spark.laravel.com/docs/6.0/installation#installation-via-composer
I'd also add that, you should never modify files in the ./spark directory. All changes are made in either ./resources/assets/js/spark or ./resources/views/vendor/spark (and, as always, you can override anything in the app directory unless you changed the namespace).
Oh, and these commands may be useful for you (obviously turn these into an actual alias or function that's aliased):
alias reset
rm -rf composer.lock node_modules package-lock.json vendor
composer install
npm install
gulp
composer validate
alias update
rm -rf node_modules vendor
composer install
npm install
composer update
npm update
reset
I would only run these as the branch master though, team members shouldn't have to do dependency updates for Composer and npm.
I just put up a package on packagist and I tried to run a composer update and am getting the error:
Unknown downloader type: h. Available types: git, svn, hg, perforce, zip, rar, tar, gzip, phar, file.
In the main project file I have this:
"require": {
//.......
"cyphix333/sbb-code-parser": "dev-master"
},
The composer.json file for cyphix333/sbb-code-parser is:
{
"name": "cyphix333/sbb-code-parser",
"description": "SBBCodeParser is a simple BBCode parser",
"keywords": [
"SBBCodeParser"
],
"homepage": "https://github.com/samclarke/SBBCodeParser",
"canonical": "https://github.com/cyphix333/SBBCodeParser",
"source": "https://github.com/cyphix333/SBBCodeParser/tree/master",
"autoload": {
"classmap": ["SBBCodeParser.php","classes/"]
},
"authors": [
{
"name": "Sam Clarke"
}
],
"require": {
"php": ">=5.3"
}
}
I am not sure what I am doing wrong here?
If you just started getting this error, try composer clear-cache and/or delete ~/.composer and vendor.
The specific error I was getting was:
[InvalidArgumentException]
Unknown downloader type: . Available types: git, svn, fossil, hg, perforce, zip, rar, tar, gzip, xz, phar,
file, path.
I just deleted everything and then tried again; works now.
I'm using
Composer version 1.2.0 2016-07-19 01:28:52
I've solved this issue deleting the vendor directory.
rm -Rf vendor
And then running:
composer update
Changes to your composer.json: dropped canonical and source; added type library.
Give this one a try:
{
"name": "cyphix333/sbb-code-parser",
"description": "SBBCodeParser is a simple BBCode parser",
"homepage": "https://github.com/samclarke/SBBCodeParser",
"keywords": ["SBBCodeParser"],
"type": "library",
"authors": [
{
"name": "Sam Clarke"
}
],
"require": {
"php": ">=5.3"
},
"autoload": {
"classmap": ["SBBCodeParser.php", "classes/"]
}
}
I did resolve this error after updating the composer version.
The installation did not work with composer v2.
Passing to the v1 version works.
composer self-update --1
I encountered this issue too, we had a human error in our composer.json. The dist part of one of our custom repositories was entered with a faulty downloader type (as stated in the error message).
{
"type": "package",
"package": {
"name": "campaignmonitor/createsend-php",
"type": "drupal-library",
"version": "dev-master",
"dist": {
"url": "https://github.com/campaignmonitor/createsend-php.git",
"type": "drupal-library"
},
"source": {
"url": "https://github.com/campaignmonitor/createsend-php.git",
"type": "git",
"reference": "master"
}
}
}
Note that the dist's type is entered as drupal-library, that is the package type, not the downloader type. We corrected this by using the following for dist:
"dist": {
"url": "https://github.com/campaignmonitor/createsend-php/archive/master.zip",
"type": "zip"
},
As we developed this project we had no problems when running composer install locally. We encountered this error when making the project production ready, using --prefer-dist. Obviously, it will only then use dist over source and then encounter this error.
Disclaimer: This case is somewhat different then the original question, though it's highly relatable and this question came up on top when trying to search for the answer. I hope this is okay.
I created a package for Laravel 4 that worked properly when used in development in workbench but when I install it with Composer it keeps returning me the error Class 'Myvendor\Mypackage\MypackageServiceProvider' not found.
There is a particularity with my package which is that the name of my classes sources are different from the name of my package. Usually they are the same.
vendor/
Houle/
laravel-dynamite/
src/
Fhoule/
Dynamite/
DynamiteServiceProvider.php
I know that it can work because Laravel work's this way too.
vendor/
laravel/
framework/
src/
Illuminate/
And the property PSR-0 of my package composer.json seems to be properly configured:
"name": "Houle/laravel-dynamite",
...
"require": {
"php": ">=5.3.0",
"illuminate/support": "4.0.x"
},
"autoload": {
"classmap": [
"src/migrations",
"src/controllers",
"src/models"
],
"psr-0": {
"Fhoule\\Dynamite": "src/"
}
},
...
How I created my package:
Created the package with Artisan.
Maked it work properly in workbench directory
Pushed to private Bitbucket repo
Installed new instance of Laravel
Changed composer.json configuration to install my package (from private repository)
"name": "laravel/laravel",
...
"require": {
"laravel/framework": "4.0.*",
"Houle/laravel-dynamite": "2.0.1"
},
"repositories": [{
"type": "package",
"package": {
"name": "Houle/laravel-dynamite",
"version": "2.0.1",
"source": {
"url": "git#bitbucket.org:Houle/laravel-dynamite.git",
"type": "git",
"reference": "v2.0.1"
}
}
}],
...
Added my package Service Provider to app/config/app.php:
'providers' => array(
'Fhoule\Dynamite\DynamiteServiceProvider',
)
That's where my application return the error Class 'Fhoule\Dynamite\DynamiteServiceProvider' not found.
What could be my issue?
I found my problem, it hadn't nothing to do with the way I named my vendor, package and classes.
It was that in my composer.json (root of the project), I set my repository type to package but like the Composer documentation states the type package is for packages that don't support Composer. That's why Composer wasn't updating my autoload_classmap.php file.
So if you want to use a private repository (like at Bitbucket or GitHub) you need to set the type of the repository to git:
{
"name": "laravel/laravel",
...
"require": {
"laravel/framework": "4.0.*",
"houle/laravel-dynamite": "dev-master"
},
"repositories": [{
"type": "git",
"url": "git#bitbucket.org:Houle/laravel-dynamite.git"
}],
...
}
Hope it helps someone.
The composer.json in your package (Package found in BitBucket) needs to specify the PSR-0 Autoloading component, rather than the composer.json file in your top-level Laravel project.
Can you show us the composer.json file for your repo in the private repository?