+1 on `earthly ls`. I've also thought it would be valuable to have "public" and "private" targets. When looking at a new codebase it can be hard to know which targets I should use when developing, and which are purely for internal use. Good docs help with this too, but they are not always there.
As someone who worked on this it was exciting to get Replay working on three platforms (macOS, Linux, Windows), hopefully proving that our strategy[1] for recording and replaying programs works.
(Replay engineer): Kind of! In the code viewer's left hand side gutter, the one that shows line numbers, if a line of code was never executed it is greyed out. Otherwise if you hover over it we show you how many times that code was executed, and from there you can set a logpoint/breakpoint.
Self-hosted is on the roadmap, but getting this to be a universal technique is definitely going to be hard, no arguments there. Gotta start somewhere though!
Replay deterministically replays the recording, so if the state of the application when you recorded it caused a network call, then when replaying it we will also "make" a network call _but_, instead of actually going out to the network we will instead return the exact data that was returned when you recorded it.
Can you expand more on what you mean by a race condition in network calls? If it's a series of network calls that the browser could make in any order than we will make them in the order that they occurred when you recorded it. If it's a race condition that occurs in your backend, then the Replay browser won't really help there (though it will show you the responses you got from your backend when you recorded it).
For help with that, you might want to use Replay on the backend. Right now we have Node support (https://github.com/RecordReplay/node), but other runtimes are on the roadmap.
(Replay engineer): In the long run we'd love for Replay to prove to the major runtimes that they should build support for this in to the runtime itself, rather than us maintaining many forks. The API that we designed for recording a runtime is open source and available here https://replay.io/driver and could serve as a good starting point.
(Replay engineer) Google is currently the only way unfortunately. We wanted to support secure logins at launch, with SSO and Multi-factor Authentication, and focus most of our efforts on the core product. As a result we just went with Google for launch.
We don't currently have any plans to add additional authentication mechanisms but we've heard this feedback from a couple folks and we'll sit down to prioritize it after the excitement of launch has died down. Sorry about that!
(Replay engineer): we basically record all the inputs and outputs to a program. In the example of an HTTP request: when recording we'd record that a request was made, and the response. When replaying, rather than make the HTTP request, we return the response that was recorded.
(Replay engineer): re: Windows, we have an alpha build out now, with a wider beta release coming later this year.
re: on-prem, it's definitely something we plan to support, and something we have engineered in to the infrastructure. If you're interested email [email protected], we'd love to talk more.
(Replay engineer): We're big fans of RR and pernosco, I love to see those tools get their due. Replay is also designed to support backend programs. We [support Node](https://github.com/RecordReplay/node) today with more runtimes coming soon.
(Replay engineer): We support all the debugger features (breakpoints, step in to, step over) and more (step back). We emphasize console.log because we found that time traveling console.logs makes for a good demo, and engineers immediately grok what is it capable of, rather than think that they need to adopt a whole new debugging workflow to use Replay.
(Replay engineer): Hey davidten, thanks for trying Replay, sorry about the confusion. You definitely shouldn't need an invite. We're on it, getting a fix out now.
(Replay engineer): That's something we'd love to enable in the future, but before we do we want to make sure that non-technical user can understand the implications of what they are sharing (a recording contains everything: every value a variable was ever set to, all network calls, cookies, etc) and has tools to redact information they don't want shared.
We definitely want to enable something like that in the future. But first we need ensure the user's privacy is maintained. Right now a recording contains _everything_: all variables, all cookies, all network requests. The challenge will be communicating to a non-technical user exactly what is shared and allowing them to redact portions of the recording, while making sure that the recording is still useful.