Composer Installation Yields Unusable Project

[knudpotente]

SUMMARY
When doing an installation of Codeception via Composer, the codecept script ends up being unusable because of a bad directory reference in Codeption's autoload.php file.

The file:
'[...]/vendor/Codeception/Codeception/autoload.php'
probably intends to load:
'[...]/vendor/composer/autoload_namespaces.php'
but instead it ends up asking to load:
'[...]/vendor/Codeception/Codeception/vendor/composer/autoload_namespaces.php'
which doesn't exist.

This renders the installation via Composer unusable. :-(

STEPS TO REPRODUCE
In a brand new directory, create a new composer.json file, as described in the installation instructions of the manual:

{
    "require": {
        "codeception/codeception":  "1.*@dev"
    },
    "minimum-stability": "dev"
}

Then, using your Terminal, cd into your new directory, and install Codeception via Composer:

composer install

If everything goes well, after a few minutes you should have your 'vendor' sub-directory, and also the Composer 'autoload.php' file in your project directory.

According to the installation instructions, you should now be able to run the 'codecept' command, found inside the 'vendor/bin' directory, like this:

php vendor/bin/codecept

Doing that, however, yields the following error:

Warning: require_once(/path/to/project/vendor/Codeception/Codeception/
vendor/composer/autoload_namespaces.php): failed to open stream: No such file 
or directory in /path/to/project/vendor/Codeception/Codeception/autoload.php 
on line 5

Fatal error: require_once(): Failed opening required '/path/to/project/vendor/
Codeception/Codeception/vendor/composer/autoload_namespaces.php' (include_path='.:') 
in /path/to/project/vendor/Codeception/Codeception/autoload.php on line 5

The user is not able to execute the codecept script.

[komex]

У меня точно такой же баг. Через composer Codeception не работает...

[DavertMik]

Yep, sorry. It might that composer updates broke current package. Because I checked the installation just before the last release. I'm going to fix that on weekend. Right now you can use the phar version as it's the most stable to any external changes. PEAR version can do the thing too.

[DavertMik]

These are the reasons I recommend using phar. It's stable. I build a package one time and it works.
In case of composer everything can be changed in any time! And that really sucks. There is no stable packages and dependencies.

For come reasons Composer generated this autoload file.

    'Symfony\\Component\\Yaml\\' => $vendorDir . '/symfony/yaml/',
    'Symfony\\Component\\Process' => $vendorDir . '/symfony/process/',
    'Symfony\\Component\\Finder\\' => $vendorDir . '/symfony/finder/',
    'Symfony\\Component\\EventDispatcher\\' => $vendorDir . '/symfony/event-dispatcher/',
    'Symfony\\Component\\DomCrawler' => $vendorDir . '/symfony/dom-crawler/',
    'Symfony\\Component\\CssSelector' => $vendorDir . '/symfony/css-selector/',
    'Symfony\\Component\\Console\\' => $vendorDir . '/symfony/console/',
    'Symfony\\Component\\BrowserKit' => $vendorDir . '/symfony/browser-kit/',
    'Selenium' => $vendorDir . '/alexandresalome/php-selenium/src/',

Just because some classes ends with "" and some are note UniversalAutoloader fails to load them.

Anyway it is fixed now )