21 ms·

The Composer project and Packagist are the catalysts which made it possible to drag PHP development out of the dark ages, but it's still got some rough edges th

The Composer project and Packagist are the catalysts which made it possible to drag PHP development out of the dark ages, but it's still got some rough edges that will eat a afternoon. Recent example: Re-organizing namespaces and classes in an internal library. Losing my mind (doing everything right) until finally realizing Composer wasn't updating the autoloader to reflect changes to the lib's composer.json. For something that works really well when it’s working, I have blown a lot of hours fighting with this stuff.

steve_adams_86 8y ago
Rebuilding the autoloader became a normal step in diagnosing issues for me. You never know... These days I deal with npm which in some ways is nicer yet it can still eat afternoons.
- mkirklions 8y ago
  So far no issues with PHP other than the occasional turn it off and back on again. NPM? Wake up on a saturday morning and hot reload + react tools no longer works? F me. On the bright side I almost finished the front end, so I can casually mess around with the solution every few days as I do my daily work in laravel.
  - steve_adams_86 8y ago
    Haha, fair enough. The other day I was getting this bizarre mismatch of versions of a dependency and I couldn't figure out how it could even matter. Like, who cares if they're two minor versions apart? Neither of them were global so there was no conflict for their parent modules. _That_ is the kind of stuff that kills me about npm. It can be really reeeaally hard to figure out what to do in those situations. Also, package.json is arguably a pretty gnarly way to organize... Well, everything? It's the kitchen sink of configuration, but it's supposed to be for managing packages. But no, you can also configure your packages in there, configure scripts for your application, etc. It's nuts. Even so, both of them are miles ahead of what we had 10 years ago!
jtreminio 8y ago
It generates a map file when you run `composer install` and many of the several other commands. Yours is not really a critique of composer, since it's not a daemon or a continuously run script. You run it once and done.
- workinthehead 8y ago
  No, it is though, because other package managers are not daemons and they don't have this problem.
  - sieabahlpark 8y ago
    Composer is optimized for how php executes which is once per request. If you want to compute namespaces per request that's your choice.
    - workinthehead 8y ago
      Well, that's not really true either since most production PHP deployments use FastCGI. The problem isn't namespaces, either, since this applies to packages that don't use namespaces. (But what kind of a language requires you to "compute namespaces" outside of runtime, anyway?) So I'm forced to conclude you don't know what you're talking about. Probably one of those butthurt PHP partisans who can't handle criticism. checks profile Ah, indeed.
  - tylerjwilk00 8y ago
    If you wish to daemonize it have a file change listener run it when it observes file system changes in the appropriate directory. If that is too much work a quick hack would be: watch -n 10 composer dumpautoloaf --no-scripts & Full disclosure: I did not verify this command would work well
dmead 8y ago
Phpstorm is a good investment.
- edgarvaldes 8y ago
  Sounds interesting, how does it help with Composer?
  - rocketpastsix 8y ago
    If you rename a class through PHPStorm, it will go through the entire codebase, find the old name and update it, including in the autoloaded class maps and files.
tylerjwilk00 8y ago
In the future, if/when you change your namespaces or add new Class files, just run: `composer dump-autoload` This will dump the autoloader and rebuild it. This is much much faster than an entire `composer install` run. For additional usage options try: `composer help dump-autoload` * Unrelated: HN can we please get better markdown?

steve_adams_86 8y ago

Rebuilding the autoloader became a normal step in diagnosing issues for me. You never know... These days I deal with npm which in some ways is nicer yet it can still eat afternoons.

mkirklions 8y ago
So far no issues with PHP other than the occasional turn it off and back on again. NPM? Wake up on a saturday morning and hot reload + react tools no longer works? F me. On the bright side I almost finished the front end, so I can casually mess around with the solution every few days as I do my daily work in laravel.
- steve_adams_86 8y ago
  Haha, fair enough. The other day I was getting this bizarre mismatch of versions of a dependency and I couldn't figure out how it could even matter. Like, who cares if they're two minor versions apart? Neither of them were global so there was no conflict for their parent modules. _That_ is the kind of stuff that kills me about npm. It can be really reeeaally hard to figure out what to do in those situations. Also, package.json is arguably a pretty gnarly way to organize... Well, everything? It's the kitchen sink of configuration, but it's supposed to be for managing packages. But no, you can also configure your packages in there, configure scripts for your application, etc. It's nuts. Even so, both of them are miles ahead of what we had 10 years ago!

jtreminio 8y ago

It generates a map file when you run `composer install` and many of the several other commands. Yours is not really a critique of composer, since it's not a daemon or a continuously run script. You run it once and done.

workinthehead 8y ago
No, it is though, because other package managers are not daemons and they don't have this problem.
- sieabahlpark 8y ago
  Composer is optimized for how php executes which is once per request. If you want to compute namespaces per request that's your choice.
  - workinthehead 8y ago
    Well, that's not really true either since most production PHP deployments use FastCGI. The problem isn't namespaces, either, since this applies to packages that don't use namespaces. (But what kind of a language requires you to "compute namespaces" outside of runtime, anyway?) So I'm forced to conclude you don't know what you're talking about. Probably one of those butthurt PHP partisans who can't handle criticism. checks profile Ah, indeed.
- tylerjwilk00 8y ago
  If you wish to daemonize it have a file change listener run it when it observes file system changes in the appropriate directory. If that is too much work a quick hack would be: watch -n 10 composer dumpautoloaf --no-scripts & Full disclosure: I did not verify this command would work well

dmead 8y ago

Phpstorm is a good investment.

edgarvaldes 8y ago
Sounds interesting, how does it help with Composer?
- rocketpastsix 8y ago
  If you rename a class through PHPStorm, it will go through the entire codebase, find the old name and update it, including in the autoloaded class maps and files.

tylerjwilk00 8y ago

In the future, if/when you change your namespaces or add new Class files, just run: `composer dump-autoload` This will dump the autoloader and rebuild it. This is much much faster than an entire `composer install` run. For additional usage options try: `composer help dump-autoload` * Unrelated: HN can we please get better markdown?