There is no exception management. For exemple if https://github.com/nikic/PHP-Parser throws an exception because of incorrect PHP file, the whole prefixing process is stopped

Example:

<?php

use Symfony\Component\HttpKernel\Kernel;
use Symfony\Component\Config\Loader\LoaderInterface;

class AppKernel extends Kernel
{
    public function registerBundles()
    {
        $bundles = [
            new Symfony\Bundle\FrameworkBundle\FrameworkBundle(),
            new \Sensio\Bundle\FrameworkExtraBundle\SensioFrameworkExtraBundle(),
            new AppBundle\AppBundle(),
        ];

        return $bundles;
    }

Will be:

<?php

use PhpScoper595ca8c756b76\Symfony\Component\HttpKernel\Kernel;
use PhpScoper595ca8c756b76\Symfony\Component\Config\Loader\LoaderInterface;
class AppKernel extends Kernel
{
    public function registerBundles()
    {
        $bundles = [
            new Symfony\Bundle\FrameworkBundle\FrameworkBundle(), 
            new \PhpScoper595ca8c756b76\Sensio\Bundle\FrameworkExtraBundle\SensioFrameworkExtraBundle(), 
            new AppBundle\AppBundle()
        ];
        return $bundles;
    }

A --diff option should be added which displays all changes as diff, but does not actually change any file.

Given the following class:

<?php

class AppKernel
{
}

which is whitelisted (hence should be prefixed), the prefixed code won't change i.e. the namespace with the prefix added is missing:

<?php

namespace PhpScoperPefix; // <- this is missing

class AppKernel
{
}

I'm trying to prefix Infection application but faced an issue with PSR-0 dependency which is not correctly resolved.

I've created a github repo with reproducible issue - just a very small application with only 1 dependency - Pimple container which uses PSR-0 in its composer.json.

How to reproduce:

git clone https://github.com/borNfreee/php-scoper-bug
cd php-scoper-bug

composer install

# check it works
php src/main.php // prints "Hello"

# run PHP-Scoper
php-scoper add-prefix --output-dir=build-prefixed --force --prefix=Mutant

composer dump-autoload --working-dir=build-prefixed/ --classmap-authoritative --no-dev

# Then try to run prefixed application:
cd build-prefixed

php src/main.php

This throws an error:

PHP Fatal error:  Uncaught Error: Class 'Mutant\Pimple\Container' not found in php-scoper-bug/build-prefixed/src/Application.php:10
Stack trace: ...

Please note that composer create autoload_static.php with the following content for PSR-0 dependencies:

public static $prefixesPsr0 = array (
        'P' => 
        array (
            'Pimple' =>  // <------- this is not prefixed
            array (
                0 => __DIR__ . '/..' . '/pimple/pimple/src',
            ),
        ),
    );

while PSR-4 dependencies are prefixed:

public static $prefixDirsPsr4 = array (
        'Mutant\\ScoperBug\\' => 
        array (
            0 => __DIR__ . '/../..' . '/src',
        ),
        'Mutant\\Psr\\Container\\' => 
        array (
            0 => __DIR__ . '/..' . '/psr/container/src',
        ),
    );

Did I miss something?

Hope this helps!

We have a binary https://github.com/humbug/php-scoper/blob/master/bin/php-scoper which I think deserves an integration test (not sure how to do it yet though).

Also the binary should be namespaced IMO, there is no reason to put it in the global namespace

We will generate a PHAR for this library which is build via make build. I think it would be good to apply PhpScoper to the generated PHAR like shown in #38

Also tests run for #43 could be applied to the generated PHAR as well.

Several paths could be taken to enhance performances:

• Using the same trick as Composer to disable xdebug when running the analysis
• See if that work can be parallelised (my only worry is concurrent creating of a same directory, otherwise should be easy)
• The biggest and quickest perf boost is to scope the least number of file as possible, for that a box optimization would be optimal (see #49)

Other perf boost could be in:

• PhpParser (hard to tell and not sure I want to dig into this one)
• Box (which is super slow as well)

In any case I think for now waiting a couple of minutes to build the PHAR is acceptable so this task is not a hight priority one

I can't find webmozart/php-scoper on packagist, is that normal?

• If prefixes are already applied do nothing
• If an error occurs, all changes are reverted

AddPrefixCommandHandlerTest tests both output and handler ops at same time (since that's what the handler is doing at the moment). Separating the concerns would probably translate into shorter unit tests, less fudging around with Symfony/Console in tests, and allow output to evolve separately.

The options --fix-strings and --fix-global-strings (suggestions for better names welcome) should be added which do the following:

In a first pass, all class names in the project are collected. Class names that already contain the prefix should be collected as well, but without the prefix (see #6). Then:

• --fix-strings adds the namespace prefix to strings that contain non-global class names, e.g. 'Composer\Autoload\ClassLoader'. This operation should be pretty safe to do.
• --fix-global-strings adds the namespace prefix to all strings that contain global class names, e.g. 'ComposerAutoloaderInitFilesAutoloadOrder'. This operation is risky since strings could look like class names even though they are none (e.g. 'Profile'), so this needs manual review. The option will typically be used combined with --diff to create a patch that can be reviewed and adjusted before being applied.

Maybe the configuration could be simplified by requiring to pass a simple function for the global namespace whitelist and patchers instead of an array of things... tbd

In the context of tools like Humbug or PhpUnit, the code shipped in the PHAR need to consume external code for which the namespaces must not be prefixed. For example PhpUnit\Framework\TestCase is a class that must be shared between the isolated PHAR and the consumer code.

This is not rewritten:

if (!class_exists('Symfony\\Component\\Yaml\\Parser')) {
     throw new RuntimeException('Unable to load YAML config files as the Symfony Yaml Component is not installed.');
}

While pointless single level namespaces will raise a warning in use, there is an exception for setting an alias. As equally pointless as that may be...

<?php
use Symfony; // raise warning
use Symfony as Laravel; // no warning
new Laravel\Component\Finder\Finder; // Symfony Finder instance

With the most recent change in scoping, any use XXX as YYY would escape scoping for now.

I had a simple file:

<?php

require_once __DIR__.'/vendor/autoload.php';

echo (new \Foo\Foo())().PHP_EOL;

Where Foo was an invokable. Surprisingly the scoping did not prefix \Foo\Foo() to PhpScoperPrefix\Foo\Foo().

AFAIK, the package for setting the version string ignores local release tags, so this will set the version for all phars to the commit hash. As we need a valid version string for updating down the line, an alternative mode when building phars (or using the phar) is needed.

I think we should provide a file discovery experience similar to box to ease the usage outside of box (and we don't know when the box integration will be done) which is easily doable by adding 2 entries in the config.

@padraic thoughts?

Hey guys,

Ran into an issue today where new static(...) is translated to new Prefix\static(...), where it shouldn't be prefixed at all.

Here's an example using an example from Guzzle: php-scoper-issue.zip

Comparing the src and build files you can see this

@@ -47,21 +41,12 @@
      */
     public static function factory($config = array())
     {
-        return new static(isset($config['base_url']) ? $config['base_url'] : null, $config);
-    }
-
+        return new \Prefix\Guzzle\Service\static(isset($config['base_url']) ? $config['base_url'] : null, $config);
+    }

The command I ran here was

php-scoper add-prefix --prefix="Prefix\\" src/

php-scoper@227a4fd

Anything I can do to help out here?

The only piece missing in the puzzle for the next part is to fix the autoloading for the whitelisted class. We can take for example PHP-Scoper itself which needs to whitelist Symfony\Component\Finder\Finder which can be used in the configuration file.

The Finder class itself is ok, the namespace is left untouched and the scoped code still uses references to the correct Finder class. The issue is for the autoloading, where before you had a PSR-4 loader with Symfony\Component\Finder => vendor/symfony/finder, you now have PhpScoperPrefix\Symfony\Component\Finder => vendor/symfony/finder. This is correct for the prefixed classes, but will fail for the autoloading of the finder class...

Currently the handler will silently skip invalid/non-existing paths or files.
Unreadable paths/files should already throw an Exception from using Symfony\Finder, but a test for that should be added.

Unlikely to have big improvements but I think having one or two simple scenario like done in https://github.com/nelmio/alice/tree/master/profiling is a good thing just to keep track of it to ensure we don't fuck up badly.

As the scoping is done file by file in a complete isolated way, it should be easy to parallelize that work.

See #142

This is a minor issue. I get the following error

Argument 1 passed to Humbug\PhpScoper\Scoper\Composer\AutoloadPrefixer::prefixPackageAutoloads() must be of the type array, string given, called in /Users/tobias/.composer/vendor/humbug/php-scoper/src/Scoper/Composer/InstalledPackagesScoper.php on line 75

Because of https://github.com/symfony/phpunit-bridge/blob/3.4/Tests/DeprecationErrorHandler/fake_vendor/composer/installed.json

Is there anyway I can specify the prefix that is being used?
I have an idea that I may be able to to a search and replace on the source code.

Background: Im trying to run the scoper on Symfony source.

Add a check to prevent the user to whitelist a class from the global namespace, e.g.Foo. Indeed they are already whitelisted and the global namespace whitelister is about scoping them when necessary. This validation can be done in the configuration.

The first task here is to create a prototype of the "add-prefix" command. The stub of this command and its test is already there. The implementation should look for all

• namespace declarations
• use statements
• fully qualified usages of class/interface/trait names

in a directory/file and add the passed prefix. Read the README to learn more. Probably we can use https://github.com/nikic/PHP-Parser to do the parsing, although I don't know whether it's possible to access the position of the parsed token in the file from the parser to do the actual string replacement (cc @nikic).

This should be fun :) This is available for grabs if anyone wants to give it a try.

https://github.com/humbug/php-scoper#phar-preferred points to https://github.com/humbug/php-scoper/blob/master/releases which results in a 404.

And https://github.com/humbug/php-scoper/releases does not offer PHAR downloads.

@theofidry I checked briefly into the PHAR problems, and it seems to boil down to PHP Parser referring to specific classes and functions using strings (which we aren't scoping). Two examples:

PhpParser\Lexer::createTokenMap():

if (defined($name = 'PhpParser\\Parser\\Tokens::' . $name)) {
    // Other tokens can be mapped directly
    $tokenMap[$i] = constant($name);
}

Straightforward class name in a string which is not scoped. This is the first problem encountered. When fixed, you find another when Pretty Printing. I assume at that point we've gone through most of the parsing, so there may just be a couple of these.

PhpParser\PrettyPrinterAbstract::p():

/**
 * Pretty prints a node.
 *
 * @param Node $node Node to be pretty printed
 *
 * @return string Pretty printed node
 */
protected function p(Node $node)
{
    return $this->{'p' . $node->getType()}($node);
}

The $node->getType() returns the class ref which is prefixed, so the function name is corrupted and causes a fatal error.

The outcome of the problem is that scoped files are empty apart from an opening PHP tag. So essentially, we need a facility to apply simple patches to files. I'm not sure if they should target before or after scoping. I suspect doing it beforehand is simpler, but debugging takes place after (and pretty printing meddles with line numbers in between). Might be useful to have a shortcut to extract the phar from php-scoper itself for ease of debugging. I'm using the following the extract the phar at the moment:

php -r '$phar = new Phar("bin/php-scoper.phar"); $phar->extractTo("./build/extract");'

Cf. box & Composer

Some functions such as is_array should be transformed into \is_array to help opcache. Maybe it could be possible to do the same trick as #117 and prefix all internal functions

Currently, the scoper outputs "..." during the process.

For a first version, we could to the same thing than php-cs-fixer: list all the paths of the processed files

/home/matthieu/www/puli/file1.php
/home/matthieu/www/puli/file2.php
/home/matthieu/www/puli/file3.php
...

Noticed when going through tests, that one checks the exit code is 0 in the event of a file not existing. Last test in AddPrefixCommandHandlerTest.

PHP-Scoper should not add the namespace prefix to classes that already contain the prefix. In this way, the scoper can be run multiple times on the same code.

The option --fix-composer should be added which adds the namespace prefix to the "autoload" section of all composer.json files found in the searched paths.

please make version show actual version. i downloaded 0.5.1, but it shows git hash:

[~/.local/bin/phars/phars (master)★] ➔ php71 ./php-scoper.phar --version
PHP Scoper version 600abecf9bd8ed8c02807c64529b9be4129b8b1e

First of all, thanks for creating this! It solves a real problem for shipping code with bundled dependencies 👍

I saw on the readme it says that the phar is coming soon, but by the looks of things it seems as though it may be possible to do yourself? I tried building the phar with make build but it's looking for box which is missing in the vendor-bin directory.

make build
# everything goes fine until this part...
composer dump-autoload -d build  --classmap-authoritative
Generating optimized autoload files
php -d zend.enable_gc=0 vendor-bin/box/vendor/bin/box build
Could not open input file: vendor-bin/box/vendor/bin/box
make: *** [build] Error 1

Am I missing something?

Currently, the coding style is not kept when files are processed by the scoper. For exemple

<?php

namespace MyNamespace;

use MyOtherNamespace\MyClass;

class MyClass
{
}

is modified like this

<?php

namespace MyNamespace;

use MyOtherNamespace\MyClass;
class MyClass
{
}

use function getcwd();

is going to be prefixed:

use function PhpScoperXXX\getcwd();

which is obviously wrong

Currently the classes without namespace (for example https://github.com/sebastianbergmann/phpunit/blob/master/src/Framework/TestCase.php) are just ignored

Follow up of #38 (comment)

I saw a box option regarding the PHAR version as well, not sure how you configure/handle it @padraic.

I am working on integrating php-scoper into the build process for phpunit.phar. Here is the current state of the relevant section from PHPUnit's build.xml:

<exec executable="${basedir}/build/tools/php-scoper" taskname="php-scoper">
    <arg value="add-prefix" />
    <arg value="--no-ansi" />
    <arg value="--no-config" />
    <arg value="--no-interaction" />
    <arg value="--stop-on-failure" />
    <arg value="--output-dir" />
    <arg path="${basedir}/build/phar-prefixed" />
    <arg value="--prefix" />
    <arg value="PHPUnit" />
    <arg path="${basedir}/build/phar" />
</exec>

The progress bar is printed although the --no-ansi option is passed:

I am reluctant to pass --quiet as I am not sure whether that would also suppress error messages.

As people use box to build their PHAR, it would be nice if the prefixing could be done directly via box by exposing a config.

This is very likely to require to switch from a JSON config file to a PHP one for Box.

See symfony/symfony#25130, in some cases inlining values could provide a performance boost.

When I try to run php-scoper add-prefix in my simple project I get an Exception:

[Symfony\Component\Filesystem\Exception\IOException]                          
Failed to create "C:\www\test\public\wp-content\plugins\asdasdasdsad\buildC:\www\test\public\wp-content\plugins\asdasdasdsad": mkdir(): No such file or directory.   

As you can see the path is duplicated. Using output dir / working dir parameters doesn't help.

I'm on Windows 10 using the MINGW64 command line.