This Issue is about:
Hello guys. I noticed that in phaser2 you included p2 and pixijs in the code base. This generates 2 problems:
And today it looks like it's becoming a problem as definitions are not up to date. And pixi release new really interesting versions...
First question: why?
Then was there an effort of collaboration with people maintaining other projects? Why not forking them and require them via npm?
This issue is no longer relevant as we prepare to move to V3. However ...
P2 hasn't been updated since November 2015. The version in Phaser 2.6.2+ is the most current. We include it wholesale, no modifications other than a few small tweaks that were never merged into a p2 release for some reason. Had they done so, we could have updated to it, but they never did. Should a new version of p2 ever be released it wouldn't take much to implement (depending on what changed.)
We absolutely benefit from the P2 TypeScript defs, as they're included in our repo and with CE, and it was the Phaser community that first created them, years ago. All _other_ communities benefit from the work we did there. We were also responsible for the first Pixi TS defs as well. So it's incorrect to say we don't benefit from the defs we created, as we do and have done for years. Fixes to them are actively maintained in Phaser CE.
Phaser 2 uses its own very specific, very customised version of Pixi 2. It's not just a fork, it would be pointless forking actually as they'd never want to merge our changes back upstream as they're specific to Phaser. In a way, I'm really glad of this because Pixi is now on version 5 and has gone through 2 complete re-writes in the past 2 years. As Phaser 2 was so tightly bound to Pixi it means we would have had to completely rewrite it, twice, just to stay current. That's a lot of work of dubious benefit when our time is best spent elsewhere.
It's not a simple case of just including it from npm and updating every now and again. To assume that is to completely fail to understand the depth of integration we have with it. When we used Pixi 2 we actively contributed back to the project. I'm still personally one of the highest contributors to Pixi 2 there was, so we absolutely helped push it forwards and tracked loads of bugs down back then.
Pixi is a marvelous piece of work, but went through too many fundamental changes, too often, for us to risk building Phaser 3 on-top of it. We're not talking small API tweaks either, the changes are seismic and we would literally have to have adopted every single one to remain using it. This is why we spent a year building our own renderer, to avoid being painted into a corner like this ever again, and to add renderer features in that Phaser, and games in general really need.
P2.JS last commit: april 2017 / Pixi.JS last version: 4
I say it precisely because you're making a v3. But with same issues.
Forks, contributions, and extensions of dependencies are solutions to customization.
Last commit to p2 that actually changed the library and not just an example is over a year old now: October 3rd 2016, and never made it to a release version yet.
Pixi 5 is in active build, clearly seen in the current branches and planning going on as they lock-off v4 from any future changes.
We have no such issues with V3, as we have no such dependencies.
@photonstorm can you tell us a little about the MatterJS physics engine, which is now part of v3? Will Phaser use an embedded (custom) version of the library, or will it switch to the upstream version later, using it as a regular dependency?
It won't be a regular dependency in its current state because it includes too many things that are pointless being in there for Phaser. If I was to include it via npm you would pay the cost of taking all its baggage with you: the Runner, the massive Render files, the Mouse handler, Metrics, etc. If this is tidied up in a future release then I'll gladly swap to using it directly.
Until that point we're contributing tests, bug reports and suggestions back to the main repo, some of which are making it in already.
The problem with 'regular dependencies' is that it makes people incorrectly assume you can just upgrade them and everything will be fine. The original comment in this issue makes that very assumption; that had we just used npm we could have upgraded them and kept up to date. It's a complete fallacy though.
I assume pixi.js follow semver, you should probably read about. That's great. And new versions are not a point to not get pixi.js from npm. It's still not a good excuse for not forking/contributing.
You may ignore it but build tools are designed to not include the whole code base. Renderers of matterjs are designed to be redefined for the one you prefer.
A good excuse for not follow best practices if that you didn't and it's too late because the deadline is too early. (which is sad anyway)
Please consider that I want to use phaser because of the great work you did (it have to be said) about integration with other libraries. But I also don't want phaser because of problems I notice and reported (they are huge, you should care).
I don't get your "not a good excuse for not forking / contributing" comment. I'm _still_ the 9th top contributor to Pixi even though I've not touched it for several years, I contributed 16,000+ lines of code and countless hours of time to the project. Now we've started using Matter there are several enhancements in 0.14.0 that are a result of my contributions. To say I don't contribute is both incorrect and mildly offensive
Neither Phaser nor Pixi were available on npm when we integrated them, and even if it had been it still wouldn't have solved just how much we needed to customise it to be able to use it.
It's too late for Phaser 2 and CE, they are what they are. It would literally be impossible to remove Pixi from it and swap to an npm version. P2 is trivial to upgrade, but I doubt we'll ever see another release version of it anyway.
For V3 I'm happy to use matter from npm once the performance PRs have been merged, assuming we can still exclude the excess classes we don't need (because they are not excluded by build tools because Matter references them all _internally_ due to the way it has been structured.)
It's great to read that it's planned for v3. This issue was for the v3 ofc. I get that the v2 is EOL.
So I guess this discussion is only misunderstandings. I'll be happy to help with Phaser 3 if I still work in video games in some months :).
Most helpful comment
It won't be a regular dependency in its current state because it includes too many things that are pointless being in there for Phaser. If I was to include it via npm you would pay the cost of taking all its baggage with you: the Runner, the massive Render files, the Mouse handler, Metrics, etc. If this is tidied up in a future release then I'll gladly swap to using it directly.
Until that point we're contributing tests, bug reports and suggestions back to the main repo, some of which are making it in already.
The problem with 'regular dependencies' is that it makes people incorrectly assume you can just upgrade them and everything will be fine. The original comment in this issue makes that very assumption; that had we just used npm we could have upgraded them and kept up to date. It's a complete fallacy though.