feat: Adding serialization types relevant to the new Dataconnection classes
- Exposes LogLevel to be used by the user in a typescript setting
- Adding the new Serialization types to the enum and using that enum in the relevant class
- Uses npx rimraf rather than rm -rf for build command for easy compatability
- (Possibly subject to change/rejection) Changing the SerializationMapping type to enforce all all types of serialization existing in the map (see comment in code) :
- One concern id raise over doing this is that it locks the user into ONLY the SerializerTypes that we provide, Changing this back to the following reverts this
[key: string]: new ( peerId: string, provider: Peer, options: any, ) => DataConnection; - Removed Serialization.Default and instead provide a default serialization in the class.
- This is to prevent situations where the default constructor is used but the other peer doesn't have it loaded in the mapping
- Error handling if the serializer is not in the mapping
An example of creating the options with a custom set of serializers would look like this:
const peerOptions: PeerOptions = {
host: PUBLIC_HOST,
port: parseInt(PUBLIC_PORT),
path: PUBLIC_PEERPATH,
debug: LogLevel.All,
serializers: {
cbor: Cbor,
}
};
let peer = new Peer(peerOptions);
Very welcome PR!
BrowserStack fails because this comes from an external fork, if you would like to contribute to PeerJS in the future, I could add you to the organization.
Please don’t be afraid to open 10 new small PRs instead of one with multiple edits. That also keeps review times short.
Very welcome PR!
Thank you!
BrowserStack fails because this comes from an external fork, if you would like to contribute to PeerJS in the future, I could add you to the organization.
Yes please, I would be more than glad to contribute more, I have another contribution in the works as well!
Please don’t be afraid to open 10 new small PRs instead of one with multiple edits. That also keeps review times short.
Yep yep, thank you for the advice, will follow going forward.