Skip to content

Typing improvements for io and fixes for websocketclient, and a few others #1429

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 25 commits into
base: public
Choose a base branch
from

Conversation

cmidgley
Copy link
Contributor

This is the work I've done to date with io focused on making websocketclient to be reliable and strongly typed with TypeScript. It's a fairly substantial set of changes, mostly in the .d.ts files but some implementation (especially websocketclient).

Type changes:

  • New types for embedded:io/socket/tcp/tls, embedded:network/http/server, embedded:network/http/server/options/webpage, embedded:network/https/server/options/websocket, and embedded:network/websocket/client
  • Improvements to types embedded:io/socket/listener, embedded:io/socket/tcp, embedded:io/socket/udp, embedded:network/dns/resolver/udp, embedded:network/http/client, embedded:provider/builtin
  • Added Device (for global variable device) into global types to eliminate requirement for import
  • Extend the global namespace for Device for when imports of extended modules are used (support for embedded:network/http/server, embedded:network/websocket/client)

Implementation changes:

  • Bug fixes/improvements for websocketclient:
    • Implement error property via onError(error: string) (new feature)
    • Fix issue where control message payloads were not being decoded with the mask (data corruption)
    • Fix an issue where masks were used on both client and server (spec requires masking on client to server only)
    • Fixed issue where fragmented reads used an improper mask (data corruption)
  • Fix a bug in websocket where using attached sockets would fail (reported in embedded:io/socket/listener locks up Win simulator #1428)
  • Add common HTTP status codes to httpserver on the HTTP/1.1 <status> <code> header
  • Added options feature to embedded:network/http/server/options/webpage to support .contentType and .status.

I typed everything based on the current implementation and not ECMA-419 (many modules are inconsistent with the published 2nd edition of the spec).

@cmidgley cmidgley changed the title Typing improvements for io and fixes for websocketclient`, and a few others Typing improvements for io and fixes for websocketclient, and a few others Oct 21, 2024
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this change. It must fix a problem you see. But, it also would require the caller to set host, port, and path in the options object, which isn't what we want.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch - on review I see I misunderstood what it was doing. I'll fix...

@cmidgley
Copy link
Contributor Author

Fixes are in place. Let me know what else you find..

- tls extends tcp instead of full definition
- Add 'undefined' as possible `read` result
set format(format: string);
get format(): string;
}
export default class TLSSocket extends TCP {}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm no TypeScript expert, but don't you need to define that the TLSSocket constructor uses TLSOptions instead of TCPOptions for the options object argument?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for filling this in. The change is good. I don't want even more copies of the HTTP status code map in the repo. I'll make a module for those so it can be shared. But that doesn't need to hold this up.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

419 UDP only specifies udp.read() - no argument and returns ArrayBuffer augmented with port and address. It does not specify multicast (though that's definitely on the roadmap)

socket: TCPDevice | TLSDevice;
port?: number;
host: string;
dns: DNSUDPDevice;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no requirement that this is a DNS using UDP. It could be another resolution transport. But, for the moment this is probably OK?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say we add a generic DNS type when we have more, and change ClientOptions to use that (or just DNSUDPDevice | DNSOtherDevice here). Either way, it won't be a breaking change as it is just expanding the type. But using 'any' (or 'undefined') isn't a good alternative as it isn't strongly typed.

cmidgley added 4 commits May 2, 2025 08:38
…pstream changes), fix TLSSocket constructor type, remove paramaterized UDP.read
…ce is defined; remove udp.read(buffer); add TLSSocket.constructor with TLSOptions definition
@cmidgley
Copy link
Contributor Author

cmidgley commented May 3, 2025

Merged latest code and resolved conflicts. Reviewed io changes since initial PR and applied typing changes as needed. Removed some no-longer-needed code changes as they are now in base. Applied changes based on review comments from Peter. This has been working great for me for the last seven months (on an older version of Moddable) and compiles/passes all my tests with latest code.

Ready for review and possible merging.

@phoddie
Copy link
Collaborator

phoddie commented May 15, 2025

Finally coming back around to this.... there's so much here that it is a little challenging to review. I'm not asking that you split it up, but it is a bit of an adventure to understand and review.

That said, a lot of it looks good and we should get it merged. The *-device stuff is a bit confusing. I think I'm starting to understand it though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants