-
-
Save EmanueleMinotto/7f1df17741f85d7a3bd3 to your computer and use it in GitHub Desktop.
/ | |
Acme | |
Package | |
Library.php | |
LibraryTest.php | |
composer.json | |
.gitignore | |
.gitattributes | |
acmescript |
/.gitattributes export-ignore | |
/.gitignore export-ignore | |
/phpunit.xml.dist export-ignore | |
*Test.php export-ignore |
vendor/ | |
phpunit.xml | |
composer.phar |
#!/usr/bin/env php | |
<?php | |
// ... |
{ | |
"autoload": { | |
"exclude-from-classmap": [ | |
"*Test.php" | |
], | |
"psr-4": { | |
"Acme\\": "Acme" | |
} | |
}, | |
"bin": [ | |
"acmescript" | |
] | |
} |
Is Package some kind of seperator for different project parts?
Acme\Package\Library
follows PSR-0 & PSR-4, I've just remove the common src/
part.
Is only one vendor dir (like Acme) possible?
Is usally recommended to use a single vendor for every package, bundle, module, etc... the same concept exists on packagist.org with vendor/*
Why are tests in the same directory like its tested code?
Why not? Them could be excluded from library distribution and/or Composer (already lazy) autoloading with the exclude-from-classmap
option.
This could be useful too to prevent namespace importing in the tests/
directory, often I see something like this:
namespace Acme\Vendor\Tests;
use Acme\Vendor\Package;
class PackageText extends \PHPUnit_Framework_TestCase
{
protected $obj;
public function setUp()
{
$this->obj = new Package;
// or using PHP 5.5+
$this->obj = $this->getMock(Package::class);
}
}
instead with this you can do:
namespace Acme\Vendor;
class PackageText extends \PHPUnit_Framework_TestCase
{
protected $obj;
public function setUp()
{
$this->obj = new Package;
// or using PHP 5.5+
$this->obj = $this->getMock(Package::class);
}
}
What about project config?
Project configs should be shared in the project root or on the environment for not required things (for example: the .idea for PHPStorm).
Why the vendors name in the bin directory (acmescript)?
There isn't a bin/
directory, considering that every package shares a single bin script (in this example it's acmescript
), it could be included in the same level of the project configuration.
I would have:
dist # if you have JS/CSS scripts, minified version
doc
src
Dummy.php
tests
Dummy.php
resources # if you have JS/CSS scripts
composer.json
.gitignore
.gitattributes
.editorconfig
.travis.yml
README.md
LICENSE.md
... config files
@theofidry I am using you variant, I think it's need to be a best practise in all projects
Agreed with @theofidry, I'm doring like that as well.
Finally found the time to reply, first of all: thank you for your comments :)
Uhm @theofidry your structure makes sense, but is it based on a document? Still seems something custom (dist/
more than other directories).
Package
some kind of seperator for different project parts?Acme
) possible?acmescript
)?