archipelago.js@3.0.0 Planning and Task Tracking

[ThePhar]

Creating an issue for tracking planned features, deprecated apis, etc for version 2.1 3.0 of the library.

The goal is to maintain backwards compatibility for clients that have moved to 2.0 for the time being, while improving the interface and capabilities for new or future users.

• Add client option to return all arguments for any event as an object, instead of positional parameters.
  • Requires opting in on the Client object, otherwise returns the positional arguments instead of an object.
  • A deprecation warning to be displayed that the positional parameters version will be removed in version 3.0, where it will become the default.
• On the MessageEvents.message event, include a property with the event type, for easy filtering without setting up event listeners for all other message types.
• Create a "ready" system for all managers after initial connection to before Client.login resolves, especially for cases where data needs to be fetched from storage.
  • Deprecate ItemEvents.hintsInitialized after this, since it should use the ready system and thus will never be needed as the client won't resolve until all hints are loaded (to be removed in 3.0.0).
• Add events for the following scenarios:
  • A player's status changed.
• Expose the underlying network item object on Item as needed.
• Ensure all items, players, and hints pass equality checks.
• Add support for extending client capabilities via user-defined manager objects.
  • Create an example with the Gifting Specification and create npm package.
  • Add known extensions to documentation.

More potentially to come.

[ThePhar]

Most of this is getting pushed out to a 3.0 release.

[airbreather]

Jotting down a comment for my own wishlist of things to add:

• split out a package with just the core API protocol declarations. everybody needs the packet declarations, and there's only one correct way to do them, but the rest of the package is a bit on the opinionated side. WebSocketStream is coming at some point, e.g., which someone might want to use at some point and I don't think we could really support