Mmm... well... no, but this is just my opinion: believe me, there are no "ready-made solutions" out there, at least for "non-fake-developers" or if You are really developing "something" in order to solve a feat/issue (I've encountered so many peoples that install Wordpress themes/plugins and call themself "developers").
You asked for advices and I am giving some, but You don't have to do what I am telling You, I am just outlinining some points that came from experience:
What I am talking about is at a lower level: if you are using a package manager such as Composer, NPM, Cargo, etc. You are "injecting" a piece of software into your software (that is an approach that even OS - Linux - use very widely).
The package's content is not made by a holy ghost, so You have to always check what it does at its root, or at least have a general idea: it could impact compatibility, security and performance very badly and, from a developer point-of-view, is always worthed checking code made by others, simply because You are always learning or even just stating to approve or reject that package.
On the other hand we WANT/NEED those packages because the process described above it has probably been iterated over and over by other developers that came from different background and different experience.
Every single developer could potentially spot/fix something that the previous creator did not know: the problem is that every developer has his/hers way of building/organizing things that can be productive only for him/her and this - believe me - can be a mess.
That concept may apply at a "code" level (ways of doing a operation by enhancing its performance or readiness) or mostly at an "architecture" level (for example Your solution may work in an Nginx/Apache environment, but what happen when You are using something like Swoole or RoadRunner? and what about containers? tests? code standards?)
Moreover if You are in the loop and see things at higher level, You'll realize that very different "packages"/"frameworks"/"libraries" re-use (or just simply re-write) something that has been first developed in an other language/platform, and that is powerfull because You are not tied to a single language, but You understand the engineering process behind.
For example the frameworks that I've mentioned in my earlier comment were not random (ROR, Laravel, Adonis, Masonite, etc.). If You look at them you'll see that they all use same concepts and even "syntax" of calling things, even if the underlying implementation and language feats is very different: if You came from Laravel and You know what a "migration" or a "seeder" does, You will probably understand the some concept in Adonis (Node) but so other people around the world.
When You use these tools it is your wisdom or experience that tells You the proper way to use a tool (a hammer can't do the work of a screwdriver and viceversa).
It is imperative that before even approaching a package or an entire framework You DO need to know the vanilla language very well (for example real React developers are really good at vanilla Javascript): so I don't think that - on a productive point-of-view - there is such thing like "Laravel developer" VS "PHP developer" and if there is probably someone will "pay the bill" sooner or later.
I simply think that "strictness" (in the code or in the architecture) is there for a reason, and on a long term is very productive, resilient and portable: but there is nothing wrong in writing your own stuff if You feel confident and productive - however is always worthing analyzing how other devs who encountered the same issue/challenge solved or just organized things.
Bye
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Mmm... well... no, but this is just my opinion: believe me, there are no "ready-made solutions" out there, at least for "non-fake-developers" or if You are really developing "something" in order to solve a feat/issue (I've encountered so many peoples that install Wordpress themes/plugins and call themself "developers").
You asked for advices and I am giving some, but You don't have to do what I am telling You, I am just outlinining some points that came from experience:
What I am talking about is at a lower level: if you are using a package manager such as Composer, NPM, Cargo, etc. You are "injecting" a piece of software into your software (that is an approach that even OS - Linux - use very widely).
The package's content is not made by a holy ghost, so You have to always check what it does at its root, or at least have a general idea: it could impact compatibility, security and performance very badly and, from a developer point-of-view, is always worthed checking code made by others, simply because You are always learning or even just stating to approve or reject that package.
On the other hand we WANT/NEED those packages because the process described above it has probably been iterated over and over by other developers that came from different background and different experience.
Every single developer could potentially spot/fix something that the previous creator did not know: the problem is that every developer has his/hers way of building/organizing things that can be productive only for him/her and this - believe me - can be a mess.
That concept may apply at a "code" level (ways of doing a operation by enhancing its performance or readiness) or mostly at an "architecture" level (for example Your solution may work in an Nginx/Apache environment, but what happen when You are using something like Swoole or RoadRunner? and what about containers? tests? code standards?)
Moreover if You are in the loop and see things at higher level, You'll realize that very different "packages"/"frameworks"/"libraries" re-use (or just simply re-write) something that has been first developed in an other language/platform, and that is powerfull because You are not tied to a single language, but You understand the engineering process behind.
For example the frameworks that I've mentioned in my earlier comment were not random (ROR, Laravel, Adonis, Masonite, etc.). If You look at them you'll see that they all use same concepts and even "syntax" of calling things, even if the underlying implementation and language feats is very different: if You came from Laravel and You know what a "migration" or a "seeder" does, You will probably understand the some concept in Adonis (Node) but so other people around the world.
When You use these tools it is your wisdom or experience that tells You the proper way to use a tool (a hammer can't do the work of a screwdriver and viceversa).
It is imperative that before even approaching a package or an entire framework You DO need to know the vanilla language very well (for example real React developers are really good at vanilla Javascript): so I don't think that - on a productive point-of-view - there is such thing like "Laravel developer" VS "PHP developer" and if there is probably someone will "pay the bill" sooner or later.
I simply think that "strictness" (in the code or in the architecture) is there for a reason, and on a long term is very productive, resilient and portable: but there is nothing wrong in writing your own stuff if You feel confident and productive - however is always worthing analyzing how other devs who encountered the same issue/challenge solved or just organized things.
Bye