For some reason we never initially typed the socket events. I have remedied this per the Socket.io docs.
This defines event handler types in the backend under src/types/socket.ts. The handlers in the backend are updated to use these types which ensures that event names and arguments strictly match the defined type. This applies to both the events the backend listens to and those it emits.
Similarly, the frontend defined event handler types under src/types/socket.ts, however these derive from the types defined in the backend. This is achieved through npm workspaces allowing us to import the backend types via @nos/backend/src/types/socket. This works fine for now, but I think longterm it could be a good move to introduce a third package within the monorepo for types, which both frontend & backend depend on as I have had to modify the frontend CI to also install the backend packages. A third package for types would be ideal as it would be very lightweight (ideally no dependencies) to minimise additional CI runtime.
This does not change any functionality, however greatly facilitates the ease of future changes by adding strict type safety.
For some reason we never initially typed the socket events. I have remedied this per the Socket.io docs.
This defines event handler types in the backend under
src/types/socket.ts. The handlers in the backend are updated to use these types which ensures that event names and arguments strictly match the defined type. This applies to both the events the backend listens to and those it emits.Similarly, the frontend defined event handler types under
src/types/socket.ts, however these derive from the types defined in the backend. This is achieved through npm workspaces allowing us to import the backend types via@nos/backend/src/types/socket. This works fine for now, but I think longterm it could be a good move to introduce a third package within the monorepo for types, which both frontend & backend depend on as I have had to modify the frontend CI to also install the backend packages. A third package for types would be ideal as it would be very lightweight (ideally no dependencies) to minimise additional CI runtime.This does not change any functionality, however greatly facilitates the ease of future changes by adding strict type safety.