Pixi.js: Add types for the packages

[Dairnon]

Currently to import stuff with tree shaking working, we need to do stuff like

import { Sprite } from '@pixi/sprite'

This is fine except that we don't have type support yet, so its hard to figure out which module we are trying to grab.

It'd be even better if we could get the types to start giving us hints as soon as we write import {
so for example when we type import { Sp it auto show us anything with Sp in the name

If that's not possible at the very least getting types for the @pixi part would help a bunch.

• pixi.js version: _e.g. 5.0.0-rc

[englercj]

It'd be even better if we could get the types to start giving us hints as soon as we write import {
so for example when we type import { Sp it auto show us anything with Sp in the name

That part is completely up to the editor, vscode does this for example.

The idea to solve this would be to generate a module definition for each package, then combine those into typings for the bundles.

[bigtimebuddy]

There are three build flavors for bundles: ESM, CJS, UMD. People that consume with their browsers will use UMD bundles, and people using bundlers like Webpack and Rollup will consume ESM for the most part, with CJS as a fallback. All the individual sub-packages are only built for ESM and CJS (no browser-supported builds).

Currently, we define the global PIXI object in all three flavor for bundles (but not in the sub-packages). I think we should change this and only define PIXI for UMD bundles. This would make things a little cleaner, would better support tree-shaking in Webpack/Rollup, but would drop support for importing using import "pixi.js" and using APIs via the global PIXI object.

All that is to say, I think that we should generate individual package typings, but we might need to think a little differently about the tsd-jsdoc implementation, which relies mostly on namespacing. @englercj , do you have thoughts about supporting module definitions?

[englercj]

I definitely want to support module definitions in tsd-jsdoc. The challenge lies in jsdoc having poor support for actually defining them well.

I have some experiments locally, but I need to iterate more to get somewhere I am happy with. If anyone has strong feelings about how it should work, or just knows a syntax they want to use in jsdoc that is very helpful. Please post such things on the tsd-jsdoc repo.

[englercj]

I'm looking into it this weekend.

Problem I am encountering is that jsdoc is bad at parsing es2015. Our hack to fix es6 names also breaks my ability to know if something was export named or default.

There is also the problem that it requires us to remove all the PIXI. prefixes on everything and instead reference them through their module names (module:@pixi/app~Application for example).

Trying to figure out the best way to do this, but jsdoc was written for pre-es2015 code and the syntax to get it working feels bad. esdoc may be a better alternative, but I'm going to have to keep trying things and I'll let you know what I find.

Probably won't get done with it this weekend.

[Dairnon]

We removed the PIXI global for the module stuff correct?

@englercj

Were you able to figure out how to move forward with this?

[englercj]

I had an idea to use @package but just haven't gotten around to building it. Other things are taking priority in life at the moment. Open to PRs!

[Dairnon]

btw why even export stuff as "default"

Aren't named exports better?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

[bigtimebuddy]

Reopening this issue. We are close on this.