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

Add e2e tests for consecutive changing runs #3666

Merged
merged 1 commit into from Apr 28, 2023

Conversation

yguedidi
Copy link
Contributor

second prerequisite for #3614

// so we can use helper classes here
require_once __DIR__ . '/../vendor/autoload.php';

$e2eCommand = 'php '. $rectorBin .' process --no-ansi -a '. $autoloadFile;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

this new runner removed the --dry-run option

Comment on lines +22 to +26
if (isset($argv[1]) && $argv[1] === '-o') {
$expectedDiff = $argv[2];
} else {
$expectedDiff = 'expected-output.diff';
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

and adds support for a specific expected output file

@yguedidi
Copy link
Contributor Author

@samsonasik fixed

@yguedidi
Copy link
Contributor Author

@samsonasik Seeing that this PR make #3614 fails, I get a bit confused..
Then I thought more about it and it's quite logical, as after the fist run the the file get cached in that intermediate version of it, and so no consecutive changes in the second run as the file will be skipped.

But I'm wondering if it's really a use case we want that users have to run Rector multiple times to get the final fixed version of a fila?
I don't think so, me I'd like to run Rector once, and be confident that it mades all the needed changes.

@TomasVotruba @samsonasik what do you think?

@yguedidi yguedidi marked this pull request as draft April 23, 2023 09:36
@yguedidi
Copy link
Contributor Author

@samsonasik made it a draft PR meanwhile we discuss the above point

@samsonasik
Copy link
Member

Consecutive run can happen, when changed node just reprinted, and require the print to build the new type, and then, next run of Rector required to finalize it, in rector-src, that happen by rectify auto commit CI until no longer change.

@yguedidi
Copy link
Contributor Author

yguedidi commented Apr 23, 2023

I understand it can happen, but I believe from a user perspective it's not something expected.
I think we could find a solution to that issue so users to have to deal with that.
If this seems OK for you I can try to comme with a solution

@samsonasik
Copy link
Member

Rector auto refresh type and continue to next rule by default, but on some cases, eg: add new line and spacing, that need to be re-read after.

That known limitation https://github.com/rectorphp/rector#known-drawbacks

Trust me, that expected to have multiple run.

@yguedidi
Copy link
Contributor Author

I do trust you, I'm just wondering why can't we make that "second run" programatically in some optimized way, so it's not up to end users, as I think they will expect Rector to do its full job by one run.
Do you know if this need for a second run (because of the need to re-read after) comes only from code style rules like NewlineAfterStatementRector?
Because the Known Drawbacks you linked to explain that Rector is not about styling because based on AST, so I would propose to remove all code style rules from Rector, if they are the only onces requiring that second run.

@yguedidi
Copy link
Contributor Author

Maybe you know why some code styling rectors were introduced in the first place?
Personally I'd favor caching and speed execution and leaving code style to tools dedicated to that, than supporting few code styling rectors with the drawback of a needed second run and no possibility to have a trustable cache

@samsonasik
Copy link
Member

That's complex, it is not only that, that just an example, other factor can happen, eg: on multiple re-print consecutively , rector expected to stop, otherwise, that will be infinite loop.

@yguedidi
Copy link
Contributor Author

eg: on multiple re-print consecutively , rector expected to stop, otherwise, that will be infinite loop.

is this covered by I test? I may try something :)

@samsonasik
Copy link
Member

Mostly on multiple rules usage, you can see tests/Issues directory

@yguedidi
Copy link
Contributor Author

@samsonasik just opened #3672, it would be awesome if you can have a look and give your feedback :)

@yguedidi
Copy link
Contributor Author

@samsonasik meanwhile the discussion get finalized in #3672 , let's move forward on this one as it's aligned with the current maintainers vision :)
If things change in the future we always can adapt this test

@yguedidi yguedidi marked this pull request as ready for review April 28, 2023 06:44
@yguedidi
Copy link
Contributor Author

@samsonasik marked as ready for review, as I would like to advance on #3614 so that I can benefit from a reliable cache in my day to day work :)

@staabm
Copy link
Contributor

staabm commented Apr 28, 2023

fwiw, we also experienced problems with a stale cache in our daily work.

@samsonasik samsonasik merged commit 3cf8e88 into rectorphp:main Apr 28, 2023
38 checks passed
@samsonasik
Copy link
Member

Thank you @yguedidi

@yguedidi yguedidi deleted the e2e-consecutive branch April 28, 2023 07:30
@yguedidi
Copy link
Contributor Author

@staabm I'm on it! soon expect it to be fixed :)

@TomasVotruba
Copy link
Member

I wonder if we can improve this experience 🙂

This stmts rule can have custom interface check, right?

@samsonasik
Copy link
Member

samsonasik commented Apr 29, 2023

@TomasVotruba this test make sure that multiple runs can still apply, on use case extract one statement to multi statements, then add new line between them, which the the line information is only can be fetched after rector done, which expected.

@yguedidi
Copy link
Contributor Author

This stmts rule can have custom interface check, right?

@TomasVotruba It's not clear to me what you mean here, sorry.

Would #3672 proposed PR be a better experience in your opinion? :)

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