Symfony 3.3 Flex

composer require maker

=>

[InvalidArgumentException]
Could not find package symfony/maker-bundle at any version for your minimum-stability (stable). Check the package spelling or your minimum-stability

Hi,

When we generate a controller from the make:controller command and Twig is available, the template generated is invalid: it uses the getParameter method which is not available on a AbstractController.

We use $this->render() in make:controller to render a pretty page :). But we cannot do that if TwigBundle is not installed. In that case, we should generate a simple new Response().

Some questions:

1. Is that possible to create entities or controllers with namespaces?
2. How to disable creating repository class while making doctrine entity?

Always with the aim of making our developments faster, would it be interesting to introduce some override:* commands for overriding all what is possible to override from core and third-party bundle? For instance:

• override:template
• override:error-pages
• override:route
• override:entity

I tried this bundle today and was quite surprised to find that the generated PHP files do not contain declare(strict_types=1);. I can't see any reason for that since this bundle itself requires PHP 7 anyway. Is there some other reason? Or should I send a PR?

In the same spirit of make:controller but for those who prefers ADR action instead controller

By example:

<?php

namespace App\Action;

use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;
use Symfony\Component\HttpFoundation\Response;

class ShowCategory
{
    /**
     * @Route("/category", name="category")
     */
    public function __invoke()
    {
        return new Response('Welcome to your new action !');
    }
}

I have time to add a PR tomorrow I think

There are too many people that have just 7.0 installed and we would be way more welcoming to them and every newcomers if things worked out of the box here with eg Ubuntu LTS.

Hi, since 1.1 and changes to the MakerInterface I'm unable to find good way to write own makers that are not inside MakerBundle. I want keep them in my code and register through tag.

Hardcoded class in MakerCommand

$generator = new Generator($this->fileManager, 'App\\');`

https://github.com/symfony/maker-bundle/blob/master/src/Command/MakerCommand.php#L91

Hardcoded templatePath in Generator class

$templatePath = __DIR__.'/Resources/skeleton/'.$templateName;

https://github.com/symfony/maker-bundle/blob/master/src/Generator.php#L130

I'm trying to find the best solution, without hacking this, is there a recommended way I missed? I can't think of any in this case.

In order to be able to implement the security part of symfony, in my opinion it can help people to have the whole user stack generated

Since the only thing they will to do is to configure guard for this.

WDYT ?

see #41 for an implementation and testing if you want this in the Maker Bundle.

At the time of speaking there are no CI running the tests for the repository. Do we keep using travis ou do we add something like CircleCI ?

As a chore, we should remove service autowiring and auto-registration.

There are 2 reasons:

A) make the bundle faster in dev (no autowiring)
B) give the services non-class ids (no auto registration + use traditional-style ids) so that the commands don’t display in debug:autowiring

Hello,
I'm currently using this bundle with Symphony 3.4 to create custom makers.
According to the documentation, this bundle depends on Flex, and I had to remove the Flex dependency check to make it run.

If I understand correctly, the Flex dependency is there because the default makers (controllers, entities, ...etc.) make use of the new Flex file structure. But in the case of custom makers, it's a shame that one can not use this bundle with "Flexless" Symfony 3.4...
Wouldn't it be enough to show a warning message like "Beware, default makers will only work in a Flex environment" ?
Or have I missed anything ?

Thanks in advance ;-)

Maybe this is something obvious but wondering...

Within the repo code we use short array syntax [] but in docs (https://symfony.com/doc/current/bundles/SymfonyMakerBundle/index.html) we are using older one - array().

Shouldn't this be unified?

Hi guys!

This maker command would generates a new (form) type extension class under src/Form/Extension/ and the argument is the extended type class (the class name is derived from it).

What do you think?

In old behaviour with doctrine when you add or remove some attribute, the new entity is updated and you dont have to delete it and recreate it again.

Currently the behaviour is a warning message saying that the entity file already exists and it doesn't update the new parameters. Even if probably this could be done via doctrine migrations, probably at initial stages when you build you anemic model, you don't have clear all the attributes and it is needed to update frequenly the entity.

Hello,

tried command make:entity Color
Entity has successfully generated, but getting this error when trying to run website.

The "App\Repository\ColorRepository" entity repository implements "Doctrine\Bundle\DoctrineBundle\Repository\ServiceEntityRepositoryInterface", but its service could not be found. Make sure the service exists and is tagged with "doctrine.repository_service".

Generated Repository:

<?php

namespace App\Repository;

use App\Entity\Product\Color;
use Doctrine\Bundle\DoctrineBundle\Repository\ServiceEntityRepository;
use Symfony\Bridge\Doctrine\RegistryInterface;

class ColorRepository extends ServiceEntityRepository
{
    public function __construct(RegistryInterface $registry)
    {
        parent::__construct($registry, Color::class);
    }

    /*
    public function findBySomething($value)
    {
        return $this->createQueryBuilder('c')
            ->where('c.something = :value')->setParameter('value', $value)
            ->orderBy('c.id', 'ASC')
            ->setMaxResults(10)
            ->getQuery()
            ->getResult()
        ;
    }
    */
}

I have a question:
Why we can't configuration path to template of different commands?
For example to pass option path_to_skeleton.

The documentation covers a lof of other boilerplates, but theses one are less common. So, we can imagine the next commands:

• make:security:guard doc
• make:serializer:encoder doc
• make:profiler:data-collector doc
• make:security:form-login doc
• make:monolog:processor doc
• ...

This bundle is interested only by the most common makers or these previous examples are potentially to include in this project?

Hello,
let's say I keep my entities in ./src/Entity/ but I want to organize it better, so I've decided to split entities into other directories, for example ./src/Entity/Shop/ and other in ./src/Entity/Auth/
how do I achieve this using php bin/console make:entity? Is there a way to do this?

http://symfony.com/doc/current/form/create_custom_field_type.html

Although the class has the same methods available as the one generated by the make:form command, it's a bit different from what is needed for custom form field types.

Skeleton:

namespace App\Form\Type; // <-- different location (src/Form/Type)

// ...

class <?= $form_type_class_name ?> extends AbstractType
{
    public function buildForm(FormBuilderInterface $builder, array $options)
    {
    }

    public function buildView(FormView $view, FormInterface $form, array $options);
    {
        // this method is commonly used rather than buildForm
    }

    public function configureOptions(OptionsResolver $resolver)
    {
        $resolver->setDefaults([
            'option_name' => null, 
            // most of the time it is not a compound form, so data_class option is rare
        ]);
    }

    public function getParent()
    {
        // we might need a good default parent, may be:
        return TextType::class;
    }
}

Creating a template for the field (if Twig is available):

{# templates/form/fields.html.twig #}
{% block <?= $form_type_block_name ?>_widget %}

{% endblock %}

Configuring the form theme template (if Twig is available and it is not configured):

# config/packages/twig.yaml
twig:
    form_themes:
        - 'form/fields.html.twig'

Should we add this feature to the current MakeForm (through a flag option) or would it be a new maker make:form-type?

Hi there.

May be we can change InputConfiguration to handle options like autocomplete and validation? It will help us to simplify custom makers and brings ability to make complex interaction automatically.

Example changes

If no one mind, I will create PR and we can discuss the best way to improve this part of bundle :)

This is a small first step towards my bold plan of having the MakerBundle completely reinvent the experience of working with Symfony security :).

When you run make:auth, I would like to also update the user's security.yaml file. In future commands (like make:user) I would like to make even more changes to this file. But, there are some complications:

• We must update the file without changing anything else - like spacing or comments. That means Yaml::dump() is out of the question

• We must be able to smartly detect that there is only 1 firewall and update it (i.e. we need to be smart enough to detect and ignore any dev firewall)

• Before writing the new security.yaml file, we should validate that our new YAML is valid YAML.

• If we cannot figure out how to patch their security.yaml, then we should not do it and print a clear message and what they need to do at the bottom.

Hey guys,
Currently, unless I missed the option somewhere, when I do

$ bin/console make:con

 Choose a name for your controller class (e.g. OrangeKangarooController):
 > NameController

It create a controller using annotations.

/**
 * @Route("/name", name="name")
 */

What do you think of asking for the desired route name, path and the strategy:

$ bin/console make:controller

 Choose a name for your controller class (e.g. OrangeKangarooController):
 > NameController

Choose a path (default: name)
> some-path

Choose a route name (default: name)
> some-name

Annotations or yaml? (default: Annotations)
> yaml

If you think this could be an interesting feature, I could give it a try.
Cheers.

Hi all.
The idea is to hide DependencyBuilder from Maker and simplify dependency configuration.

Exapmle

Now we have:

public function configureDependencies(DependencyBuilder $dependencies)
{
    $dependencies->addClassDependency(
        Route::class,
        'annotations'
    );
}

After:

public function getDependencies(): array
{
    return [
        Route::class => ['package' => 'annotations']
    ];
}

I understand that it's BC break, but we have #120 which is already a BC break, and we can combine it if community and @weaverryan doesn't mind

Hi,
It will be great to add support a generation of the translation file.
At this moment it can be done by creating custom Generator, because at this moment it is not possible to override existing file.

To create a reusable bundle is a little boring. SensioGeneratorBundle have a command for this. Why not have a similar command here?

Maker Bundle is not registering make commands, although I've followed the instructions in the docs carefully.

> composer create-project symfony/skeleton my-app
> cd my-app
> composer require maker --dev
> php bin/console list make

Symfony 4.0.2 (kernel: src, env: local, debug: true)

Usage:
command [options] [arguments]

Options:
  -h, --help            Display this help message
  -q, --quiet           Do not output any message
  -V, --version         Display this application version
      --ansi            Force ANSI output
      --no-ansi         Disable ANSI output
  -n, --no-interaction  Do not ask any interactive question
  -e, --env=ENV         The environment name [default: "local"]
      --no-debug        Switches off debug mode
  -v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug

2017-12-25T15:41:30+01:00 [error] Error thrown while running command "list make". Message: "There are no commands defined in the "make" namespace."

There are no commands defined in the "make" namespace.

list [--raw] [--format FORMAT] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-e|--env ENV] [--no-debug] [--] <command> [<namespace>]

uname: CYGWIN_NT-10.0 (Windows 10)
php -v: PHP 7.1.3 (cli) (built: Mar 14 2017 23:33:35) ( NTS MSVC14 (Visual C++ 2015) x64 )
composer --version: Composer version 1.5.6 2017-12-18 12:09:18

Also, it says env: local although APP_ENV=dev is set in .env.

https://symfony.com/doc/current/bundles/SymfonyMakerBundle/index.html#creating-your-own-makers

Creating your Own Makers
------------------------

In case your applications need to generate custom boilerplate code, you can
create your own ``make:...`` command reusing the tools provided by this bundle.
Imagine that you need to create a ``make:report`` command. First, create a
class that implements ...... 

... wait no no, just run make:maker report that's it! =)

What do you think?

When creating this bundle we decided to not require Twig to keep things simple. That means that our skeleton files can't have complex logic and we need to interpolate the placeholder variables ourselves. Not a big deal ... but not using Twig and not defining skeleton files as Twig templates has another problem...

... you can't easily override the skeleton files in your project (see #32 and lots of related issues in the SensioGeneratorBundle). Should we...

... add Twig as dependency and turn skeletons into templates?
... try to make the skeleton files overridable using the kernel file locator ?
... not support this feature explicitly?

Currently, the generators are hardcoding the src folder for the source. But SRC_DIR is configurable in Flex.
The bundle should read the configured value in the composer.json instead, to account for Flex configuration.

For me, one of the first downsides I have encountered while testing out Flex with Symfony4 is the missing command of doctrine:generate:entity with all the helper questions + the not working doctrine:generate:entities (see doctrine/DoctrineBundle#729 fore more info).

My previous workflow whenever I was prototyping something was:

• generate the entities with doctrine:generate:entity by answering to a couple of questions;
• I always opted for YAML mapping, so the next step was to edit the files to create the relations between entities
• updating the entities with doctrine:generate:entities to get the new properties and appropriate methods (e.g. __construct with initialized ArrayCollection objects, addElement, removeElement etc.)
• update schema

With the current make:entity command, it took me more than 4 times the time in order to get an up & running 3 entities related between them (Job, Category, Affiliate - remember good ol' Jobeet tutorial).

I would like to bring under your attention the need of migrating the functionality from SensioGeneratorBundle to the MakerBundle for doctrine:generate:entity command (very useful when first creating an entity).

Also, I would like to propose discussing the idea of migrating doctrine:generate:entities from DoctrineBundle, as the core maintainers from that project are not in favor of maintaining this command for the purpose of generating setters and getters based on mapping information.

I don't know if the 2nd proposal should be part of make:entity command or another one command.

It looks like we're starting something that may look a lot like what Drupal Console already did for Drupal.

I already talked several times with @jmolivas and @enzolutions: they built an amazing DX there, I'm sure we'll end up providing something similar, yet tailored to Symfony 4.

I'm just wondering where we can collaborate to move faster.

See https://github.com/hechoendrupal/drupal-console

Hello, I have opened this issue on the main symfony repository and I was told to do it on this one. Here is the main issue if you want to read it - symfony/symfony#25406 (comment)

Here is the idea - a command to create register and login form by providing an entity which implements UserInterface (I have seen that some think that this is a bad practice so if you really dislike UserInterface that much we can think of another requirement) and has some base options.

The command will generate SecurityController if it doesnt exist as well as login and register forms and views. It will change the route.yml and security.yml files to basically make everything needed for a login and register to work properly.

This way the user doesn't need to repeat everything mentioned in the documentation or download FOSUserBundle and then follow the documentation again. It saves a lot of time for people like me who make lots of demo projects to try new stuff (expecially after 4.0 is out).

If this command generates everything needed there is no need for any kind of magic. currently if you follow the documentation for register and login or if you download FOSUserBundle there is a lot of magic going on and you don't see the code (unless you dig into vendor folder a lot).

With that command the code generated can be dependency free (everything used by it is generated by it) and with no magic involved so that if a new user wants to use it and understand how it works he can do so very easily without having to write anything.

The command might be separated into two commands

• make:security:register
  - -algorithm={algorithm name} (default is bcrypt)
  - --withsalt determines if the user wants the encryption to use salt( default is yes)
  - -entity={entity name} (default looks for User)
  - -path={path for register} (default is /register)

• make:security:login if possible to use the options provided to make:security:register if not - repeat the same options
  - checkpath={path for check} (default is /login)
  - loginpath={path for login} (default is /login)

As you can see the two commands are under make:security which might have other commands.

I would love to participate in the development of these commands or anything to help Symfony, but I have never been part of such big repository so I would love it if there is someone willing to help me and answer my questions as I try to contribute to Symfony! If there is none - hope you guys will like the idea so that I can use it!

My Entity name is "App\Entity\DepartmentPo"
After make:crud in controller a get method

App\Controller\DepartmentPoController.php

    public function index(DepartmentPoRepository $departmentPoRepository): Response
    {
        return $this->render('department_po/index.html.twig', ['departmentPos' => $departmentPoRepository->findAll()]);
    }

templates\department_po\index.html.twif

    {% for department_po in department_pos %}

In the controller defines "departmentPos" varible but in twig we trying find "department_pos".
I think the problem in the entity name "DepartmentPo".

To repeat:

• bin/console make:entity
• Just hit enter when asked the question

The validation is correct. But why not give the user another try? We all deserve second chances! :)

maker-bundle can not generate controllers in subdirectories, or at least it is not in the documentation of how to do it.

I already tried the following options
1.- People:ProfessionController
2.- People\ProfessionController
3.- People/ProfessionController

If somehow this option is not created, it would be good to enable it for all bundle commands. And apply it with the first option.

Hi,

how can I generate a form type class based on an existing entity class, like in the old generator bundle:

doctrine:generate:form

http://symfony.com/doc/current/bundles/SensioGeneratorBundle/commands/generate_doctrine_form.html

Can this be done with the Maker bundle?

This bundle actually does not replace the current generator bundle as it was more focused on a CRUD generator. Is it something we want to do here as well?

Since doctrine/doctrine-fixtures-bundle has a very nice Flex support, why not including it in this bundle, too?

Related with #2 and #49

What about a new target option for each command that allows us to change the target directory where the final skeleton file is generated?

For example make:unit-test FooTest always creates the file class inside tests/ directory, but as the best practice recommends:

By convention, the tests/ directory should replicate the directory of your bundle for unit tests. So, if you're testing a class in the src/Util/ directory, put the test in the tests/Util/ directory.

Something like this make:functional-test FooTest --target=tests/Util will be great to not move each generated file to the corresponding directory and change its namespace.

src/Doctrine/DoctrineEntityHelper.php
line 45
$entityClassDetails = new ClassNameDetails($metadata->name, 'App\\Entity');

src/Maker/MakeCommand.php
line 91
$generator = new Generator($this->fileManager, 'App\\');

Hi I have a question

• why not use dependency injection in make commands ?

example generate an entity in with the doctrine config:
https://github.com/symfony/recipes/blob/master/doctrine/doctrine-bundle/1.6/config/packages/doctrine.yaml#L13

Maybe add support for Symfony 3.3 + Flex? Right now old generator is not working with flex and this one is for SF3.4+

Hi
Could it be great to use the constant in
https://github.com/symfony/http-kernel/blob/master/Kernel.php (MAJOR|MINOR_VERSION)
to change the value of "current" in https://github.com/symfony/maker-bundle/blob/master/src/Command/MakeEntityCommand.php#L69
could define it in the abstractcommand and use it in the subcommand ?

so that it is a real link depending on the dev sf version :)

has the fields interaction just not been added yet, or was it a conscious choice to leave it out?

This has been something we've debated. I just had a long conversation with @nicolas-grekas about it, who feels pretty strongly about pushing this best practice now. I don't feel too strongly, and certainly we need to do this at some point. Since MakerBundle is for Symfony 4 (so new projects, or people who have upgraded and are fully using the new features), this is a great place to push the best practice.

If you install Symfony 4 from scratch you will install:

• symfony/config (v3.3.*)

The marker-bundle as a dependency on v3.4, which I don't see tagged properly in Packagist? Only seeing 3.4 RC, BETA, etc...

If you do:

• composer require maker

After a completely fresh install of Symfony 4.0 you will get the error:

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for symfony/maker-bundle ^1.0 -> satisfiable by symfony/maker-bundle[1.0.0].
    - symfony/maker-bundle 1.0.0 requires symfony/config ^3.4|^4.0 -> satisfiable by symfony/config[3.4.x-dev, 4.0.x-dev, 4.1.x-dev, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2, v4.0.0-BETA1, v4.0.0-BETA2, v4.0.0-BETA3, v4.0.0-BETA4, v4.0.0-RC1, v4.0.0-RC2] but these conflict with your requirements or minimum-stability.

If I try to install 3.4 or 4.0 via: "symfony/config": "^3.4|^4.0 I get:

λ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - The requested package symfony/config ^3.4|^4.0 is satisfiable by symfony/config[3.4.x-dev, 4.0.x-dev, 4.1.x-dev, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2, v4.0.0-BETA1, v4.0.0-BETA2, v4.0.0-BETA3, v4.0.0-BETA4, v4.0.0-RC1, v4.0.0-RC2] but these conflict with your requirements or minimum-stability.
  Problem 2
    - symfony/framework-bundle v3.3.9 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
    - symfony/framework-bundle v3.3.8 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
    - symfony/framework-bundle v3.3.7 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
    - symfony/framework-bundle v3.3.6 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
    - symfony/framework-bundle v3.3.5 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
    - symfony/framework-bundle v3.3.4 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
    - symfony/framework-bundle v3.3.3 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
    - symfony/framework-bundle v3.3.2 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
    - symfony/framework-bundle v3.3.13 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
    - symfony/framework-bundle v3.3.12 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
    - symfony/framework-bundle v3.3.11 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
    - symfony/framework-bundle v3.3.10 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
    - symfony/framework-bundle v3.3.1 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
    - symfony/framework-bundle v3.3.0 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
    - symfony/framework-bundle v3.3.13 requires symfony/config ~3.3 -> satisfiable by symfony/config[3.3.x-dev, 3.4.x-dev, v3.3.0, v3.3.0-BETA1, v3.3.0-RC1, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9, v3.4.0-BETA1, v3.4.0-BETA2, v3.4.0-BETA3, v3.4.0-BETA4, v3.4.0-RC1, v3.4.0-RC2] but these conflict with your requirements or minimum-stability.
    - Installation request for symfony/framework-bundle ^3.3 -> satisfiable by symfony/framework-bundle[v3.3.0, v3.3.1, v3.3.10, v3.3.11, v3.3.12, v3.3.13, v3.3.2, v3.3.3, v3.3.4, v3.3.5, v3.3.6, v3.3.7, v3.3.8, v3.3.9].

Is maker not compatible with Symfony 4 at this time? Is Symfony 4 docs out of date?

Hi to everybody.
The new 1.1.0 makerbundle return error during object creation ( entity, form, controller etc ).
The version 1.0 work correclty
I'm working under Window 7 and Windows 10 environments
This is the verbose output:

2018-02-21T10:21:45+00:00 [debug] Warning: mkdir(): No such file or directory
2018-02-21T10:21:45+00:00 [error] Error thrown while running command "make:entity -vvv prova". Message: "Failed to create "C:\PHPDevelopment\mrc//C:\PHPDevelopment\mrc\vendor\composer/../../src/Entity""
2018-02-21T10:21:45+00:00 [debug] Command "make:entity -vvv prova" exited with code "1"

In Filesystem.php line 106:

[Symfony\Component\Filesystem\Exception\IOException]
Failed to create "C:\PHPDevelopment\mrc//C:\PHPDevelopment\mrc\vendor\composer/../../src/Entity"

Exception trace:
Symfony\Component\Filesystem\Filesystem->mkdir() at C:\PHPDevelopment\mrc\vendor\symfony\filesystem\Filesystem.php:682
Symfony\Component\Filesystem\Filesystem->dumpFile() at C:\PHPDevelopment\mrc\vendor\symfony\maker-bundle\src\FileManager.php:55
Symfony\Bundle\MakerBundle\FileManager->dumpFile() at C:\PHPDevelopment\mrc\vendor\symfony\maker-bundle\src\Generator.php:162
Symfony\Bundle\MakerBundle\Generator->writeChanges() at C:\PHPDevelopment\mrc\vendor\symfony\maker-bundle\src\Maker\MakeEntity.php:77
Symfony\Bundle\MakerBundle\Maker\MakeEntity->generate() at C:\PHPDevelopment\mrc\vendor\symfony\maker-bundle\src\Command\MakerCommand.php:93
Symfony\Bundle\MakerBundle\Command\MakerCommand->execute() at C:\PHPDevelopment\mrc\vendor\symfony\console\Command\Command.php:252
Symfony\Component\Console\Command\Command->run() at C:\PHPDevelopment\mrc\vendor\symfony\console\Application.php:883
Symfony\Component\Console\Application->doRunCommand() at C:\PHPDevelopment\mrc\vendor\symfony\framework-bundle\Console\Application.php:84
Symfony\Bundle\FrameworkBundle\Console\Application->doRunCommand() at C:\PHPDevelopment\mrc\vendor\symfony\console\Application.php:241
Symfony\Component\Console\Application->doRun() at C:\PHPDevelopment\mrc\vendor\symfony\framework-bundle\Console\Application.php:72
Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at C:\PHPDevelopment\mrc\vendor\symfony\console\Application.php:143
Symfony\Component\Console\Application->run() at C:\PHPDevelopment\mrc\bin\console:39

make:entity [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-e|--env ENV] [--no-debug] [--] []