Import `PIXI` instead of requiring it to exist globally.
Closed this issue · 11 comments
When including pixi-tilemap in a bundle, being forced to make sure that pixi,js is included before pixi-tilemap is very prone to errors. For me, my IDE automatically reorders the imports to be in reverse order, which would cause problems in the future. Whilst easily work-aroundable, it would be very nice if pixi-tilemap would not implicitly rely on the PIXI global existing, and rather import it.
This is currently breaking the latest version of pixi-tilemap
@eranimo please elaborate, whats wrong there? i still cant figure out how to make all those modules
I think the package needs a bit of love to support the ES6 module system and CommonJS projects.
It is possible by having a correct set-up project and a package.json containing a proper exports config.
I am currently struggling with this issue as well, and there are many pitfalls regarding that. I might come up with a pull-request to solve that. But I cannot guarantee that old projects still work correctly since I ultimately would deprecate the global PIXI object.
we are experimenting with pixi-tilemap, and new pixi.js 5.4 rc1 , im waiting for rc2. When one plugin will be ready - i'll move everything else
previously, when i tried to move to modules, it ended bad. several times. there's also something that is missing that's wasnt possible to do using es6 modules. The whole approach was fucked up because lack of necessary build tools.
How did I unfuck it: I invented "global mixins" approach and it will be posted in 5.4 rc2
Hm, I've yet to see a mixin solution that brings something good to the table.
Care to share?
This is the story: https://github.com/pixijs/pixi.js/pulls?q=is%3Apr+global+mixins+
This is one of files: https://github.com/pixijs/pixi.js/blob/dev/packages/mixin-cache-as-bitmap/global.d.ts
I skimmed the issues and PR's, but I can't see when or how these global mixins are introduced.
Even though it might be better to have this conversation somewhere else.
Anyway, I'll continue working on my fork and come up with a PR as soon as it is ready.
Basically, we introduce interfaces in global scope, that we implement in PixiJS. That interface can be changed in other modules. To support this perversion and ensure correct generation of docs / types we had to experiment. a lot.
Sounds interesting. Hopefully, it works out as planned. 👍
I've added my proposal to solve the module compatibility issues as PR, tested it locally with the examples and my current project. It seems to be working without any issues so far.
@ivanpopelyshev for the health and longevity for pixijs and its plugins I believe it would be really good to have this. I think a lot lof developers will be initially put off by some of these old school javascript paradigms and the hacks you have to apply to get it to work in a modern setup.
#110 fixes the global PIXI problem