3 ms·
Honestly, as a PHP développer, the node's module system impress me A LOT. I went on several projects that had not kept their dependencies on the "edge version"
by n0n0n4t0r 4y ago
Honestly, as a PHP développer, the node's module system impress me A LOT.
I went on several projects that had not kept their dependencies on the "edge version". For some, it was more than a year of work just to be able to move from php7 to php8.
PHP dependencies are so intertwined that for projects that abuse and use more than a reasonable amount (aka their ability to invest time keeping them and the code using it up to date) the update process can become a nightmare of complexity.
Node's module system let you move each dependency at it's own pace. This is such a breath!
The problem is that when you only know of the solution of your ecosystem, it's hard to see the added value you miss out.
- tored 4y agoMy recommendation for every PHP projects that uses external libraries is to use your own wrapper function/class to minimize contamination of the project. If you use a framework then try to write all your own code outside of the framework and pass in all needed framework data as arguments to your own classes/functions.
- n0n0n4t0r 4y agoI agree with you: this is a good practice. However, what I was speaking about is the version handling of (sometimes direct but mostly) indirect dependencies. The domain of `composer why` and `composer why-not`. One if the most speaking example I can think of is: if two libs depends on guzzle 5, then you can't update only one on a version that depends on guzzle 6: you must upgrade both at the same time. Each to an intercompatible lock on guzzle version.