Skip to content

Latest commit

 

History

History
39 lines (26 loc) · 4 KB

CONTRIBUTING.md

File metadata and controls

39 lines (26 loc) · 4 KB
Raw

TC39-TG3: Source Maps Contribution Guide

Thanks for helping out in the source map effort. The following guide is meant to help you get to know our workstreams, meetings, and plans.

Joining Us!

  1. We are a TC39 task group! To contribute, you'll need to be added either as a TC39 delegate or an invited expert. If you are already a delegate, you can find our meetings on the TC39 calendar. If you're interested in becoming a delegate, or would like to be added as an invited expert, join our Matrix room and message jkup (@jkup:matrix.org).
  2. We use Matrix for our chat rooms. You can find our main room here: https://matrix.to/#/#tc39-tg4:matrix.org

Documents

Workstreams

  • Meetings. We currently have 2 different recurring meetings.
    • Public feature meeting. Open to all TC39 delegates, this is where we talk about new features we'd like to add to the specification. They can be found under the naming label on GitHub.
    • Public general meeting. Open to all TC39 delegates, this is where we talk about errors or vague bits of the specification. We discuss issues found under the correctness label on GitHub.
  • Testing. We're still early stages but this is one of the most important things to focus on. When we present our updates to the main TC39 plenary, we need to have browsers and tools using these tests in accordance with our process document.

Constituencies

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 stand alone debuggers. These are tools that have access to the source map and the generated code.
  3. Post-hoc debuggers. Tools like Sentry and New Relic. These tools have access to an error stack trace and a source map.

Testing

We've been categorizing our testing efforts into three groups, each matching with a constituency.

  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, Firefox tests) 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 are working correctly.