8000 Symfony 6.4: make:crud fails with -q: $controllerClassName must not be accessed before initialization · Issue #1391 · symfony/maker-bundle · GitHub
[go: up one dir, main page]
Skip to content

Symfony 6.4: make:crud fails with -q: $controllerClassName must not be accessed before initialization #1391

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.

Sign up for GitHub

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

Jump to bottom
Closed
tacman opened this issue Nov 6, 2023 · 4 comments
Closed

Symfony 6.4: make:crud fails with -q: $controllerClassName must not be accessed before initialization #1391

tacman opened this issue Nov 6, 2023 · 4 comments
Labels
Bug Bug Fix

Comments

@tacman
Copy link
Contributor
tacman commented Nov 6, 2023 •
edited
Loading

Using Symfony 6.4, make:crud generates

In MakeCrud.php line 131:
                                                                                                                             
  Typed property Symfony\Bundle\MakerBundle\Maker\MakeCrud::$controllerClassName must not be accessed before initialization  

symfony new test-crud --webapp && cd test-crud
composer config extra.symfony.allow-contrib true
echo "DATABASE_URL=sqlite:///%kernel.project_dir%/var/data.db" > .env.local
composer require orm-fixtures --dev        
echo "officialName,string,48,no," | sed "s/,/\n/g"  | bin/console make:entity Official
bin/console make:crud Official -q

One problem is that it is missing dependencies, but the error message isn't shown when argument are being passed. But it's curious that webpack doesn't include these.

composer require form validator security-csrf

Secondly, there's no way to do interactive anymore because of the tests question. So it fails on the -q. I can replace that make:crud line with the quirky but functional sed command:

# bin/console make:crud Official -q
echo ",," | sed "s/,/\n/g"  | bin/console make:crud Official

So a working version of the above is this. But -q should work as well.

symfony new crawler-7 --webapp --version=next --php=8.2 && cd crawler-7
composer config extra.symfony.allow-contrib true
echo "DATABASE_URL=sqlite:///%kernel.project_dir%/var/data.db" > .env.local
composer require orm-fixtures --dev        
composer require form validator security-csrf      
echo "officialName,string,48,no," | sed "s/,/\n/g"  | bin/console make:entity Official
echo ",," | sed "s/,/\n/g"  | bin/console make:crud Official
@tacman tacman changed the title Symfony 6.4: MakeCrud::$controllerClassName must not be accessed before initialization Symfony 6.4: make:crud fails with -q: $controllerClassName must not be accessed before initialization Nov 6, 2023
@weaverryan
Copy link
Member

Is it the "-q" that causes this? Does -q prevent interact() from being called? https://github.com/symfony/maker-bundle/blob/main/src/Maker/MakeCrud.php#L94

If it does, that's not really the behavior we want. All maker commands are interactive and must be interactive.

@tacman
Copy link
8000 Contributor Author
tacman commented Nov 7, 2023

Yes, that's exactly the issue. interact() isn't calls, and that's the only place $this->controllerClassName is set.

I have a bundle that wrap console commands in a web interface, which makes debugging much easier (e.g. dumps, dds, and asserts). It collects the arguments and options and then runs the command using zenstruck's excellect console-extra. In fact, I'm trying to use it right now to figure out where to add the widget options in #1392, and is run non-interactively. And for testing I try to put together a bash script that can recreate an issue starting with symfony new...

I think bin/console make:crud EntityName -q used to work. All that is to say that I quite like the ability to run all console commands non-interactively.

        $defaultControllerClass = Str::asClassName(sprintf('%s Controller', $input->getArgument('entity-class')));

        $this->controllerClassName = $io->ask(
            sprintf('Choose a name for your controller class (e.g. <fg=yellow>%s</>)', $defaultControllerClass),
            $defaultControllerClass
        );

@tacman
Copy link
Contributor Author
tacman commented Feb 20, 2024

There's still an issue with -q for make:crud

symfony new test-crud --webapp && cd test-crud
composer config extra.symfony.allow-contrib true
echo "DATABASE_URL=sqlite:///%kernel.project_dir%/var/data.db" > .env.local
composer require orm-fixtures --dev        
echo "officialName,string,48,no," | sed "s/,/\n/g"  | bin/console make:entity Official
bin/console make:crud Official -q

@jrushlow jrushlow added the Bug Bug Fix label Feb 20, 2024
@jrushlow
Copy link
Collaborator
jrushlow commented Feb 20, 2024 •
edited
Loading

I don't think -q can be used with any of the make:* commands. -q silences the output.. As Ryan said, maker commands are designed to be interactive... this is failing because of how we initialize properties in many of the Maker*::class objects.

Typically you init a property via the __constructor, but when your property is dynamic, e.g. needs some input like the name of a property for an entity - we must get this input via interact().. When -q is passed to the command, it in essence never calls $this->someProperty = $io->ask('Whats the name of this'). Deeper down under the hood, it does call that method, but -q prevents any output, in turn it also is preventing any input via a visible prompt. Later on in generate() when we call $this->some-property, you'll get the PHP Initialization error.

The sed command I believe is working because even tho the ask() prompt is never shown to the user, it still exists in the galaxy... The arguments are ultimately passed to ask() via linux magic :)

In maker itself, I'm opposed to adding something like sed or any other mechanism that takes away from the interactivity of the commands. Mainly because if a question is added / changed, the sed logic will break. In a roundabout way this would add an additional layer of BC that we would attempt to maintain and would fail miserably at doing so...

Many *unix commands don't work on windows... Adding if($this->isWindows) in our test suites sucks.... our test suite is very brittle in general just because we are basically supporting and testing every symfony component that exists.. this takes a lot of time and effort and things break often...

Lastly, from experience in maintaining MakerBundle, anytime we've added some of the "niche" features/fixes/etc in the past, (supporting -q) would be an example here, 2 years later I'll merge a PR that breaks that niche support and it ends up taking alot of time trying to fix the issue... In reality, we do get alot of help from other symfony/community members (HUGE thank you to them!) in maintaining symfony/maker-bundle, but the majority of the work is done by @weaverryan && myself. Our test suite plays a big part in that... but thats a story for another day..

In short, -q is inherited from the symfony/command component and is not supported by MakerBundle. We love asking console questions and getting feedback in the terminal :)

< 5B63 /p>

@jrushlow jrushlow closed this as not planned Won't fix, can't repro, duplicate, stale Feb 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug Bug Fix
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@weaverryan @tacman @jrushlow
0