Feature suggestions

[introwit]

Comment your feature suggestions in this thread so you and we can track, discuss & work on them

[Braunson]

It would be neat to be able to see along side the packages that are install any that have existing updates available.

Another feature that could be helpful is an adapter or event for example Bugsnag, when your app throws an fatal error (for example, could be any level of error defined by this package's config), it would include a system report with installed packages and their version.

[introwit]

@Braunson thank you for considering to suggest features for this package :) And yes the first feature suggested by you is been mentioned in the roadmap . Can you explain the second feature a bit more as it sounds really nice to have anything similar in the package

[Braunson]

@introwit Ah yes sorry must have read-over that on the roadmap.

As for the second feature, if I was using some type of third-party error service, such as Bugsnag it would be nice to send additional information (such as the system report decomposer provides) to Busnag with certain levels of errors (presumably this level would be set in the decomposer's config) alongside the actual error's being logged.

[introwit]

@Braunson ok so what I have understood is that if the user is already using an error service, every time that service logs an error it logs the system report with that error as well. Correct me if I am wrong

[ajitbohra]

@introwit +1 for the feature mentioned by @Braunson good use case :)

[introwit]

@ajitbohra yes I agree. Waiting for @Braunson 's reply so that if he has anything in mind like how he wanted to apply this feature as a user so I can code that feature into the package the same way making its application quick & easy for users :)

[REBELinBLUE]

How about the ability to register other checks? For example my laravel app requires certain extensions or PHP functions to be enabled, so it would be useful if they appear in the report so when people give me their install info I can see if those are there

[introwit]

@REBELinBLUE this seems a better use case for one of the feature added in the roadmap that allows other packages/non-decomposer stats to be added in the system report. As you suggested this would be really nice to have in the package considering your given use case, thank you Stephen for that :) Feels good when the actual users suggest things he needs. Definitely adding this feature in the coming updates, will keep you posted with the development progress on it for sure :)

[Braunson]

@introwit Yes exactly, being able to pass the system report from decomposer through to that third party :)

[introwit]

@Braunson seems like a very nice feature. Noted! Will keep you posted with the development progress of it for sure over here. Thanks much Braunson again :)

[xitude]

Feature request: Write to Readme file so we can see them in github/bitbucket.

[introwit]

@xitude can you elaborate more on this?

[xitude]

@introwit, one of my biggest issues with taking over projects is keeping an eye on dependencies. If I could get it to print to the readme file so I can commit it and see it on entry to the project repo that would a life saver.

[introwit]

@xitude I found it a bit overwhelming to understand with regards to the Markdown report already being generated that can be copied and used anywhere. Also in the next release you will get the feature to produce the same report & get it as an array anywhere in your code. Can you give me an example use case so that will help me to understand what exactly your need is and work on it :)

[introwit]

@Braunson here you go getReportArray with the v1.1 release :) , @REBELinBLUE working on adding extra checks, seems to be sorted for app users, just waiting to make it dynamic so that other package developers can add their checks as well with the same process while developing their package, any suggestions?

[introwit]

@ryanvade first of all sorry for being late to respond was stuck in some issues. And yeah do you think all of these info will be useful for someone? Like any specific case where these info might come in handy rather than just the server name that is being displayed now?

[Shkeats]

A great and simple feature would to serve a json response as well, this could easily be monitored by other applications and services.

[ryanvade]

@introwit I manage so many servers with different purposes and software sets that I forget what version server X is on or if updates for server Y are available. Yes these features are available on other 'management' platforms but providing view capabilities to site admins would certainly alleviate the management issues I have. With that in mind, it seems fit that I look into it. The good news is most of these features can be implemented by simply reading files (using system calls from PHP has always concerned me).

[ajitbohra]

@Shkeats idea sounds interesting @introwit your thoughts

[introwit]

@Shkeats how can I forget the JSON response damn! Thanks for pointing it out, coming in the next release for sure, will update you :) @ryanvade makes sense, though confused how can we arrange that info in the UI. Any suggestions before I jump into it?

[introwit]

@Shkeats Json response is now available, hope you like it :) @Braunson @ajitbohra @REBELinBLUE @ryanvade @xitude You can now add your own personal extra stats as well if required 🎉

[ajitbohra]

@introwit package is really shaping up good getting more useful with every update POWER!

[felorhik]

This would likely require extra configuration. But this is another idea.

I do find that sometimes issues, minor or major for an app might get lost as development progresses. What I mean is you may notice an issue, find / post it in the issue tracker, then forget about it since you moved on to a different section and such. For instance a Queue issue in laravel that is affecting your app, there is an issue posted in github and discussions are made, finally leading to a resolution / pull request that then closes the issue and "fixes" it.

So you could add a config file with an array that you could list like

'issues' => [
   'laravel/laravel' => '#321'
]

This would then have a section in decomposer to just show the status of that issue, is it closed? is it open? Would be useful to keep track of issues affecting your app and catch when they are resolved, for even third party packages.

This would open up the workflow that once you notice an issue, you could add it to the config, any other developers or your self will be able to see that the app is currently affected by that issue.

Really like this package, thought this would be a kind of cool addition and I can personally see a use for it, but I would be curious to see how many people might agree?

[introwit]

@jordanramstad Thank you for the appreciation Jordan :) This is a really cool addition as you said but I see a few complexities. Help me with your suggestions on them if possible, they are as follows:

• I see 2 solutions out of it that are possible right now, first is subscribing to any particular issue on any GitHub repo so you get notifications & email for any activity on them that GitHub already provides. But yeah I know that you are talking in regards with Decomposer so this doesn't makes sense in this context.

• Second, For now you may add the Issue title & link via adding your own stats that Decomposer provides out of the box so you can see that listed every time and whenever you feel you can go to that link and see the latest comment or activity on that issue thread.

• If we specifically want to achieve what you suggested, we need to decide how the UI would look for it so it comes in as actually useful & need cron jobs for it as well. Any suggestions about how should we go about these 2 things if we implement it?

[felorhik]

@introwit The idea is to give a quick notice, decomposer is meant to help with debugging or making issues. If an issue affects the app, and another developer comes it, notices the problem and plans to go to the repo to possibly add an issue, then the fact that decomposer already has a note of it and if the related issue is closed or not would save a lot of time. Github API should only really need to do 1 request per issue to just check its current status. If the status of the issue is closed, and the issue is still there, then it opens up the thought to check the version used in the composer.json and check if the issue has been fixed in a release.

Yes a simple link would work though in most cases and if that is enough that is fine. I thought this could be a cool idea but I do understand an extra feature like this might find little actual use, on paper I feel it seems good but then there is how well it translates to actual use.

As for UI it would likely just be a panel with a list, showing the title and a checkmark or cross to denote if its closed or open. I don't think cron jobs are needed though, its doubtful hundreds of issues would be added in any application, I get at most maybe 5 over the course of making an application personally.

[introwit]

@jordanramstad I agree on all the points you listed. Exploring and playing with the idea locally, will keep you posted about the development progress & problems around it for sure :) Thanks Jordan for taking your time and suggesting & discussing things that can make the package more useful 🍻

[sbramley]

I feel like it would be great to see the actual version and hash installed from the composer.lock file. We have a few dependencies that use a wild card for patch versions but knowing what version is on prod vs staging would be helpful.

[introwit]

@sbramley Thanks Sam , definitely adding to the list :) If you can just hit with a PR if possible as the roadmap is really getting long to work on alone 😅 Nevertheless the point is really good and will add this feature for sure.

[sbramley]

Hey mate, just dropped a PR into you. Let me know what you need me to add or fix, it's my first time 👍

[TheZachh]

A search feature would be great. As well as an upgrade to Bootstrap 4.