Add Phar file

[ad3n]

Add phar file for simplicity

[veewee]

We discussed the phar file in issue #42.
It seems easier to use composer to install GrumPHP in your project or globally.
At the time, we didn't find any usefull reason to create a phar file.

We would love to hear your arguments on why we should add a phar file.
Thanks!

[ad3n]

vinkla/climb#28

May be, that is the reason why you need to create a phar file instead of global composer package

[veewee]

@ihsanudin Just discussed the topic with @aderuwe: That is indeed a valid point.
We are currently working on some other improvements which we think will make it easier for developers to extend the application. This means we won't put our time in this phar feature at this moment.

If you want to speed up this feature, feel free to create a PR. Maybe @igormukhingmailcom has the time to help out?

[adam-paterson]

I've been looking into this one this morning, we need to clean up a couple of bits before we can use Box to generate a phar for us.

Found Issues:

• Autoload redeclare error due to autoload loop in bin/grumphp
• File "phar:///Users/adampaterson/Code/grumphp/bin/grumphp.phar/src/GrumPHP/Console/Helper/../../../../" doesn't exists.

[veewee]

We should also keep security in mind:
https://mwop.net/blog/2015-12-14-secure-phar-automation.html

[maxime-pasquier]

Hi,

A Phar file is a must have for your project! Think about composer, we use it because it's simple to get it everywhere.

With the current project, I failed trying to create a Phar file, because of the many hardcoded absolute/relative paths.

[veewee]

Hi @Kmelia,

We did also bump into the same issues as you trying to create a phar. I don't thinkt his will be easy and we'll need to rewrite some code for this feature. We already support many use-cases: local, global, CI, ... and need to make sure that all these cases still work.
Another problem is that GrumPHP is actually a composer plugin, which makes it a bit strange to create a standalone phar.
One last problem is that the dependencies could be local, global or in a bin folder. This makes it hard to make sure that everybody is running e.g. the tests against the same version of phpunit.
I'm starting to think that this feature will cause a lot of work / possible bugs for little gain.

[gnovaro]

Basic Tutorial
https://www.sitepoint.com/packaging-your-apps-with-phar/

[m1guelpf]

Updates?

[veewee]

No. There are some issues with the different type of paths which need to be solved before we can create a phar file. The idea is to make every path relative to the config file. This is hard to get right since we are supporting a lot of different installation types, project structures, OS, ... already. Currently I don't have the time to rework that part of the application, so unless somebody else picks it up, I don't think phar support will be launched any time soon.

[paslandau]

In depth tutorial by @theofidry https://medium.com/@tfidry/create-and-deploy-secure-phars-c5572f10b4dd

[marabesi]

would it be a good idea to release a phar that supports only one os and then rolling out updates with more os's?

[drupol]

I'm also willing to have a Grumphp PHAR available. I'm looking into it, but I run into the same issue as @adam-paterson .

[veewee]

I am finishing up working on the paths. See #644.
This would make it possible to generate phars.
Poc: veewee@7c1818f

There are some issues:

• it now requires all dev dependencies to be included
• the phpparser task seems to fail for some reason.

I guess it's also better not to include the phar generation code in the repo. But instead use a compiler / shim package as phpstan does:

• https://github.com/phpstan/phpstan-shim
• https://github.com/phpstan/phpstan-compiler

This will give us the benifit that we don't have to worry about dependencies in this project to much and we can upgrade these more easily.
(The suggested way should be to use the shim package in frameworks like magento, drupal, ...)

[drupol]

Oh great !

What's the issue with the PathHelper ?

And yes, it would be very nice to use grumphp shim indeed :-)

[veewee]

The paths helper is way to opinionated about your project strcture and is pretty much a legacy of the first grumphp version. As you can see in the issues section, there are a lot of paths related issues. Most of them are solved in the new system. Not completely there yet though :)

[drupol]

Good luck mate :-)

[veewee]

I've created a shim package based on the PR above.
Lets move the discussion in there:

https://github.com/phpro/grumphp-shim

Feel free to test it out and to improve it. The composer plugin doesn't work yet and needs to be revisited, but that phar should be useable. ("On my system" anyways :) )