As I mentioned on a previous post, one of the most recurring questions (the 2nd most to be precise) since project started is why is the installation process modifying the composer.json & composer.lock file, or why is the installer adding new libraries to "core/vendor" directory, because you know that is considered hacking the core.
And as you may know that is no longer an issue, since we release an installer you can read about on the Try the new Drupal Console installer and executable phar file
This new installer generates a new issue and question, why this executable must live inside the Drupal installation, why not accessing the console.phar from anywhere on your system, why not having a global instalation as composer or drush does.
After some code refactoring, I am happy to announce we have a new release v0.5.0 with several improvements and fixes and starting on this version we can provide this global execution feature on the Drupal Console project.
How does this change the current installation process?. I will describe it here:
Executing the installer:
Accessing console from anywhere on your system:
To access console globally move the executable 'console.phar' to a directory that is already in your PATH.
You can see how easy is to run the installation process and execute the console globally on the following animated gif:
Repeating the same exercise and putting all the pieces together as in the previous installer post. I will to show how to create a Drupal 8 module in 3 easy steps:
What is next ?, why having this global executable is important ?
I will list a few points why this new global executable is important for the lifecycle and roadmap of the Drupal Console project:
* Add a new self-update command to make easy update to new releases
* Work on the documentation, since installation process will probably not change
* Add a new set of command like site:install
* Take advantage of site aliases
* Work on this issue Integrate console with drush
* Add console commands to wrap drush commands