From c3ec11c76b93db2e84df5cad1f60451f09296f7a Mon Sep 17 00:00:00 2001 From: Jon Kuperman Date: Tue, 25 Jun 2024 13:45:32 +0200 Subject: [PATCH] Change our process to group stack trace rewriters and debuggers --- CONTRIBUTING.md | 6 ++---- PROCESS.md | 6 +++--- 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 24723b6..a43ea98 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -27,8 +27,7 @@ Thanks for helping out in the [source map effort](https://ecma-international.org We've been thinking about _source map constituencies_ in the following terms. Please feel free to suggest better titles or categorization methods! 1. Generators. Bundlers, transpilers, compilers. Tools that have access to the source code and emit (among other things) source maps. -2. Debuggers. Browsers and [standalone debuggers](https://www.replay.io/). These are tools that have access to the source map and the generated code. -3. Error monitoring tools. Tools like Sentry and New Relic. These tools have access to an error stack trace and a source map. +2. Debuggers. Browsers, [standalone debuggers](https://www.replay.io/) and stack trace rewriters like [Node](https://nodejs.org/en) and [Sentry](https://sentry.io/). When considering changes, this list of tools might be useful: https://github.com/jkup/source-map-users @@ -37,5 +36,4 @@ When considering changes, this list of tools might be useful: https://github.com We've been categorizing our testing efforts into three groups, each matching with a [constituency](#constituencies). 1. Validators. For testing generator tools, we'd like to have the ability to validate a source map on its own as well as a source map being a valid map between a source and a generated file. We did a mini hackathon day on what this might look like: https://github.com/jkup/source-map-validator -2. Debuggers. For browsers, we'd like a suite of tests that can run wherever browsers apply source maps to their debug tools like Chrome DevTools. We'd like generic tests that browsers can use showing they apply source maps correctly. My assumption is they each already have their own suite of tests ([Chrome tests](https://github.com/ChromeDevTools/devtools-frontend/blob/main/test/e2e/sources/sourcemap_test.ts), [Firefox tests](https://github.com/mozilla/source-map/tree/master/test)) for this and we'll need to figure out how to integrate with their test harness and extract a shared base of tests we all could use. -3. Stack trace validators. For tools like Sentry and New Relic, we'd like tests that ensure source maps are correctly applied to the stack trace and that new features like [Debug ID](https://github.com/tc39/source-map-rfc/blob/main/proposals/debug-id.md) are working correctly. +2. Debuggers. For browsers, we'd like a suite of tests that can run wherever browsers apply source maps to their debug tools like Chrome DevTools. We'd like generic tests that browsers can use showing they apply source maps correctly. My assumption is they each already have their own suite of tests ([Chrome tests](https://github.com/ChromeDevTools/devtools-frontend/blob/main/test/e2e/sources/sourcemap_test.ts), [Firefox tests](https://github.com/mozilla/source-map/tree/master/test)) for this and we'll need to figure out how to integrate with their test harness and extract a shared base of tests we all could use. For stack trace rewriters, we'd like tests that can show source maps being correctly applied to error stacks. diff --git a/PROCESS.md b/PROCESS.md index b02192f..6208ba0 100644 --- a/PROCESS.md +++ b/PROCESS.md @@ -20,9 +20,9 @@ When a proposal reaches Stage 3, no further improvements are possible without im ## Stage 4 (complete) -- 2 source map generators ready -- 2 interactive debuggers -- 2 stack trace decoder implementations +- 2 generators +- 2 debuggers +- 1 complete end to end workflow - Test suite is complete When a proposal reaches Stage 4, it is ready to land in the editor draft. There might still be editorial changes, but all the semantics are final.