replayio / protocol

Definition of the Record Replay Protocol

protocol

Definition of the protocol used by the Record Replay web service

protocol's Issues

Integrate protocol into the backend

Now that we publish the protocol to NPM it is widely available and documented on the site and there are few benefits to having the code be openly available.

There are also drawbacks to having another repo. The primary one being that it is harder to add new backend handlers.

Remove Internal.getAssertionFilters

This method hasn't been used in several months, and is kind of a weird concept. We can insert diagnostic assertions in JS code using environment variables when testing, which would be more appropriate.

Consider renaming script to source

The name for Debugger.ScriptId was modeled after the Runtime.ScriptId type in the chrome devtools protocol, but I don't think it fits our current or future use cases very well. For us, a script is not just a piece of JS, but anything that contains source code. So, an HTML page's content is a "script". As we support additional languages in the future this will feel even weirder, and can cause friction as people use the protocol.

I think we should rename "script" to "source" throughout the protocol. Source is a more generic term that matches what we mean here: something that contains source code.

Deploy the site when the protocol changes

Fix https://replay.io/protocol/tot/Analysis/

it looks like only https://replay.io/protocol/ works

Deploy to NPM

There are several advantages to deploying to NPM

1. other projects can pull the protocol types
2. other projects for some reason could stay on a later version
3. devtools can use the NPM version

Is this worse than what we're doing now? No, because we'll always want to update the frontend when we make a change to the protocol.