read dev-dependencies and get decomposer version

[dducro]

Get Decomposer version from the package list (default) or from the dependency list if its required by another package.

[dducro]

Its also possible to display the dev dependencies.

[introwit]

@dducro thank you for the PR :) Can you please resolve the conflicts as the code structure has changed in the v1.1 release today, so I can merge it. Also:

• For time being can you remove reading the Dev dependency part because the UI of the view also needs to be planned accordingly.
• Or if you can do that as well in the PR, it would be great!
• That improving the getting Decomposer Version part is good to go, just fix the tabs vs spaces thing as per PSR-2 and any other tweaks regarded PSR-2 if any.

Thank you for considering contributing to Decomposer and discussing every possible things.

[dducro]

I resolved the merge conflicts.

• I didn't remove reading the dev-dependencies because laravel-decomposer can reside in them (like in our case). If thats the case, it needs to fetch the version from there.
• I understand that the UI needs updating to reflect these dev-dependencies. Do you have something in mind in mind for the UI? (an extra column or append them at the end of the list with an header separating them or something else? This can be done in a separate PR)
• I didn't use tabs and I think it conforms to the PSR-2 standard.

[dducro]

Much better that you extracted all functionality to it's own class!
One question, why did you make all methods in Decomposer static?
For testing purposes it's much more testable if you use regular methods in stead.
Its pretty easy to fix, do you want me to add this in a separate PR?

[introwit]

@dducro not focusing on testing right now. So other than testing I guess there is no harm in keeping methods static. Will let you know once I feel it's the right time to include tests and I myself will be confident to ask tests from contributors and all of the testing stuff.

Wrong interpretation

[dducro]

Thanks for merging!

[introwit]

@dducro Hey just fixed the following that I missed earlier, just thought to let you know :)

• The Problem:
  After this change you made, the getReportArray() broke.

• The Reason:
  The reason was when we build the associative array for Installed packages we have the key & values as name & version respectively already from the getPackagesAndDependencies() method. But directly passing the Composer Require array which you did breaks because there is no Offset as 'name'.

• The fix:
  Changed that line back to what it was earlier.

Let me know your thoughts on it :)

[dducro]

@introwit Thats true, I probably overlooked that as well.
I changed some stuff to use getDecomposerVersion.
However the call to getPackagesArray is unchanged in this pr.
But it probably should be self::getPackagesArray($packages)
Nice that you found the issue!

(You could consider committing these changes to a develop branch. I couldn't find your fix you just mentioned.)

[introwit]

@dducro I haven't pushed it yet. Just fixed locally and next minute wrote it to you to get your thoughts on it first :)

EDIT: Yeah thinking on that idea to include the flow of pushing to a develop branch in my workflow. Also are you on twitter, so that we can connect quicker in future if needed?

[dducro]

Yes, I'm @pindakaas023, not very active on twitter though.

[introwit]

@dducro noted!

[ajitbohra]

@introwit @dducro we can have gitter chat :D