Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scoped autoloaded files not loaded (again) #1036

Open
kkmuffme opened this issue Jun 4, 2024 · 7 comments
Open

Scoped autoloaded files not loaded (again) #1036

kkmuffme opened this issue Jun 4, 2024 · 7 comments

Comments

@kkmuffme
Copy link

kkmuffme commented Jun 4, 2024

Bug report

Question Answer
PHP-Scoper version 0.18.12

#298 exists again since v18 as it was reintroduced by #864

e.g. Guzzle for example (via AWS-SDK or others)

When any of the included files is loaded already, it will not load the "scoped" version anymore at all (since they have the same hash)

Also possibly the previous (working) solution it had an issue that if for whatever reason there were 2 of the scoped library (same scoped namespace), it would load the files twice? (would need to be tested though)

Btw confusingly the FAQs https://github.com/humbug/php-scoper/blob/main/docs/limitations.md#files-autoloading state it's not suppported, but it was supported fine, since the referenced issue was fixed.

EDIT:
just realized this only worked with scoper-autoload.php which is created when whitelisting symbols.
However I'm not whitelisting anything, therefore don't even have a scoper-autoload.php to be used in the first place.

@kkmuffme
Copy link
Author

kkmuffme commented Jun 4, 2024

The solution is to just run a post-fixer (after dumping the autoloader) that will replace the hashes with new hashes that include the prefix - since it's essentially a new package with the prefix, this won't break other stuff in composer either.

Can't be fixed with scoper alone, since dumping is required, but with using a composer script that does that.

Fyi using a md5 hash of the file contents (like discussed on the original composer issue) does NOT fix this - since the file itself might have the same hash, but bc of DIR,... use in that it could load scoped files which would mean it's still broken.
Therefore the only reliable way to do this is to actually modify the hash by including the scoper prefix in autoload_static.php (and potentially autoload_files.php if that is used)

@kkmuffme kkmuffme closed this as completed Jun 4, 2024
@theofidry
Copy link
Member

#298 exists again since v18 as it was reintroduced by #864

I am a bit confused at how this is breaking it.

Btw confusingly the FAQs https://github.com/humbug/php-scoper/blob/main/docs/limitations.md#files-autoloading state it's not suppported, but it was supported fine, since the referenced issue was fixed.

Indeed that needs to be updated.

just realized this only worked with scoper-autoload.php which is created when whitelisting symbols.

I would recommend to just pick scoper-autoload.php if it exists and otherwise fallback to autoload.php. This way you don't have to think about it.

@kkmuffme would you have an actual reproducer? I think this should be fixed within PHP-Scoper and I expected it to be fixed. I've added quite a few test to this effect so if you're still encountering this in 0.18.12 it missed I missed something.

@theofidry theofidry reopened this Jun 5, 2024
@kkmuffme
Copy link
Author

kkmuffme commented Jun 5, 2024

I am a bit confused at how this is breaking it.

It's not, I didn't fully get how/why it worked previously and it's unrelated to that.

I would recommend to just pick scoper-autoload.php if it exists and otherwise fallback to autoload.php. This way you don't have to think about it.

It doesn't exist so I have to use autoload.php, where this bug exists. However I implemented a fix using the composer autoload dump script, similar to what a comment on the original issue had.

@theofidry
Copy link
Member

It doesn't exist so I have to use autoload.php

Just to clarify, what I'm suggesting is to do something like that:

require file_exists(__DIR__.'/vendor/scoper-autoload.php')
    ? __DIR__.'/vendor/scoper-autoload.php'
    : __DIR__.'/vendor/autoload.php';

it's pretty harmless and avoids wondering why things are not working if you suddenly have an exposed symbol.

However I implemented a fix using the composer autoload dump script, similar to what a comment on the original issue had.

Yes but that's a workaround. PHP-Scoper should support it, that is what this fixture is about (make e2e_035).

So if there is a case where this still breaks, help for a reproducer would be greatly appreciated.

@kkmuffme
Copy link
Author

kkmuffme commented Jun 6, 2024

Just tested with 0.18.11 (can't test 0.18.12 right now) using aws/aws-sdk-php (no other packages) with classmap authoritative and optimize autoloader options. The scoper config is default except:

'output-dir' => 'vendor-prefixed',
'finders' => [
		Finder::create()
			->files()
			->ignoreUnreadableDirs()
			->ignoreVCS( true )
			->in( 'vendor' )
			->notName( '/LICENSE|README|.*\\.md|.*\\.sh|.*\\.dist|.*\\.txt|.*\\.log|Makefile|composer\\.json|composer\\.lock|psalm-autoload\\.php|psalm\\.xml/' )
			->notPath( '/(^|[\/-])(__|\w+\.)?test(ing|s)?(__)?\//i' )
			->notPath( 'phpunit' )
			->notPath( '/\/docs\//' )
			->notPath( '/(^|[\/_-])sample/i' )
			->notPath( '/(^|[\/_-])demo[\/-]/i' )
			->notPath( 'example' )
			->notPath( '/^scoper-config.php/' )
			->notPath( '/^scoper.inc.php/' )
			->sortByName( true ),
	],
	'expose-global-constants' => false,
	'expose-global-classes' => false,
	'expose-global-functions' => false,

The autoload_static.php $files have the same keys/hashes as the default and it will load the files from an unscoped package that is loaded by something else earlier.

@theofidry
Copy link
Member

@kkmuffme so it is for a project that uses aws/aws-sdk-php or for aws/aws-sdk-php itself?

@kkmuffme
Copy link
Author

kkmuffme commented Jun 6, 2024

Project that uses aws/aws-sdk-php

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants