According to Pádraic Brady, the recently found Composer bug (details at link) has been patched and the update is available for self-upgrading. Just run “composer.phar self-update”.
The whole issue brings up convenience features vs predictability. Where do you draw the line?
It’s easy as developers, thinking like developers to say a tool should take its input and assume the user knows what he/she is doing. A good example is:
sudo rm -rf /
The Unix/Linux CLI world lives and dies (in the example above) with this expectation. If you typed or clicked it, you meant it. The GUI world has the opposite expectation, they expect a “Are you sure?” prompt.
Smart developers tailor their code to avoid common pitfalls or roadblocks. You need to tailor your choices based on your user-base.
The above example is obviously disastrous, but it applies to working around problems too. Auto-correcting problems has become a norm in dealing with user input from end-users. We’ve all been amused/horrified by our phones changing the meaning of what we are typing with our thumbs into horribly different sentences. “auto-correct” has become a well-used expression even for my parents to texts gone wrong.
Tools meant for developers usually assume you meant what you typed.
PHP devs live in a somewhat grey area, many aren’t really what you would call developers. The language is so easy for amateurs to learn that there are many people out there writing custom WordPress plugins, etc. who really don’t know what they are doing. Many only login to a command prompt on their server when the documentation for their favorite software directs them to.
For developers creating tools for use by this market, there is an interest in helping them out. Solve some common problems that get posted to their bug list, etc. That is where the danger comes from.
The goal while good intentioned misses the most important point. Helping your users avoid problems is noble, but you also need to help them avoid danger. In fact, avoiding danger should be the primary goal.