Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[Runtime] Fix class validation of composer "extra.runtime.class"#43376

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
nicolas-grekas merged 1 commit intosymfony:5.3frompiku235:5.3
Oct 14, 2021

Conversation

@piku235
Copy link
Contributor

QA
Branch?5.3
Bug fix?yes
New feature?no
Deprecations?no
LicenseMIT

This PR fixes a bug of validating a runtime class from the composer paramextra.runtime.class. When provided, it always fails. Taking as an example theRuntime\Swoole\Runtime of theruntime/swoole package, when executing thecomposer dump-autoload, it ends with the following exception, even though theruntime/swoole package was installed.

 [InvalidArgumentException] Class "Runtime\Swoole\Runtime" listed under "extra.runtime.class" in your composer.json file not found.

When a composer plugin is executed, the composer autoloader for the project is not registered, thereby any reference to a class from installed packages won't work.
The fix drops this check to avoid it. I don't think it's worth checking here if a runtime class is valid or not. For instance, anything that comes from the$_SERVER['APP_RUNTIME'] is accepted, nothing is validated.

@carsonbotcarsonbot added this to the5.3 milestoneOct 8, 2021
@piku235piku235 changed the title[Runtime] Drop class validation of composer "extra.runtime.class"[Runtime] Fix class validation of composer "extra.runtime.class"Oct 8, 2021
@Ahummeling
Copy link
Contributor

Ahummeling commentedOct 12, 2021
edited
Loading

Perhaps this issue can be resolved without omitting the check entirely. Could it be the case that theclass_exists($runtimeClass) call is responsible for the failed autoload? If so, does the issue still occur when passingfalse as second parameter to prevent calling autoload by default?

@piku235
Copy link
ContributorAuthor

piku235 commentedOct 13, 2021
edited
Loading

@Ahummelin I'd also like to keep it, but because of how things internally work for composer plugins it seems hard to get and therefore not worth it. The issue is more about theis_subclass_of() call in the if statement. When a class does not exist, it tries to reach registered autoloaders, but as the most important one - responsible for project dependencies is not registered when a composer plugin is executed, it returns alwaysfalse.

Copy link
Contributor

@AhummelingAhummeling left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Yeah I see what you mean now, going over the doc foris_subclass_of, seems that the autoloader can be disabled, but then you'd need to get an instance of the class, which was what we're trying to get around in the first place...

With that said, I think the PR looks good

@nicolas-grekas
Copy link
Member

Thank you@piku235.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@stofstofstof approved these changes

+1 more reviewer

@AhummelingAhummelingAhummeling approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

5.3

Development

Successfully merging this pull request may close these issues.

5 participants

@piku235@Ahummeling@nicolas-grekas@stof@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp