Closed bigtimebuddy closed 1 year ago
Hey @bigtimebuddy, we had a bit of discussion on slack about this cc @GoodBoyDigital @Zyie .
My thoughts were:
@pixi/react
this looks like it's a fork of react
pixi-react
rather than react-pixi
it implies that we're rendering react
inside of pixi
whereas we're actually rendering pixi
inside of react
react
related libraries to be named with the react-
prefixWhat do you think?
I see your points. That said, I still am in favor of the original proposal above for a few reasons:
In my opinion, the goal of this project should be primarily to serve the PixiJS community, and probably secondarily the React community. We have Node.js, Canvas, Webworker and OffscreenCanvas rendering... the goal for PixiJS is to expand environments where PixiJS can run. That has always been consistent with our mission (maximizing the devices, browsers and runtimes that can render PixiJS content). I look at this project as inline with that mission.
PixiJS is not in the business (and shouldn't be) of forking React. Similarly, we also have a @pixi/node
package and no one is confusing with us forking Node.js. That is not something that I'm overly concerned about.
Lastly, in terms of the react-
prefix... again, we are building this project for the PixiJS community first. I don't feel a need to use the naming conventions the React community has adopted if they have no functional benefit (as opposed to maybe babel, eslint, etc that use the convention for a configuration shorthands).
I respect the final decision of the folks here to determine what's best for the project, but I thought that this context might be helpful to how I think about the goal, mission, reach and opportunity of this project relative to the larger PixiJS project.
I have a minor suggestion to be consistent with other PixiJS ecosystem extensions:
@pixi/react-pixi
to be@pixi/react