Merge pull request #4 from dminor/update-readme-and-workflow

Update readme and workflow

Author: mgaudet

.github/workflows/build.yml

@@ -4,20 +4,22 @@ on:
   push:
     branches:
       - main
+permissions:
+  contents: write
 
 jobs:
   deploy:
     runs-on: ubuntu-latest
 
     steps:
-    - uses: actions/checkout@v3
-    - uses: ljharb/actions/node/install@main
-      name: 'nvm install lts/* && npm install'
+    - uses: actions/checkout@v4
+    - uses: actions/setup-node@v4
       with:
-        node-version: lts/*
-    - run: npm run build
-    - uses: JamesIves/[email protected]
+        node-version: 20
+    - run: >
+        npm ci --no-audit && npm run build
+    - uses: JamesIves/[email protected]
       with:
         branch: gh-pages
-        folder: build
+        folder: dist
         clean: true

.github/workflows/deploy.yml

@@ -1,53 +1,53 @@
-# Error.captureStackTrace 
+# Error.captureStackTrace
 
 **Stage**: [Stage 1](https://tc39.es/process-document/)
 
-**Champion**: Matthew Gaudet (Mozilla) 
+**Champions**: Matthew Gaudet (Mozilla), Daniel Minor (Mozilla)
 
 
-V8 has has a non-standard [Stack Trace API](https://v8.dev/docs/stack-trace-api) for a while. 
+V8 has has a non-standard [Stack Trace API](https://v8.dev/docs/stack-trace-api) for a while.
 
-In August 2023, [JSC also shipped this method](https://github.com/WebKit/WebKit/commit/997e074bb35ed07b69c9b821141c91dd548e0d02) 
+In August 2023, [JSC also shipped this method](https://github.com/WebKit/WebKit/commit/997e074bb35ed07b69c9b821141c91dd548e0d02)
 
-This method [has now turned into a web-compatability problem](https://bugzilla.mozilla.org/show_bug.cgi?id=1886820), and as a result we should now standardize it. 
+This method [has now turned into a web-compatability problem](https://bugzilla.mozilla.org/show_bug.cgi?id=1886820), and as a result we should now standardize it.
 
 ## `Error.captureStackTrace`
 
 To quote the [V8 documentation](https://v8.dev/docs/stack-trace-api):
 
 > Stack trace collection for custom exceptions
-> 
+>
 > The stack trace mechanism used for built-in errors is implemented using a general stack trace collection API that is also available to user scripts. The function
-> 
+>
 >     Error.captureStackTrace(error, constructorOpt)
-> 
+>
 > adds a stack property to the given error object that yields the stack trace at the time captureStackTrace was called. Stack traces collected through `Error.captureStackTrace` are immediately collected, formatted, and attached to the given error object.
-> 
+>
 > The optional `constructorOpt` parameter allows you to pass in a function value. When collecting the stack trace all frames above the topmost call to this function, including that call, are left out of the stack trace. This can be useful to hide implementation details that won’t be useful to the user. The usual way of defining a custom error that captures a stack trace would be:
-> 
+>
 >     function MyError() {
 >       Error.captureStackTrace(this, MyError);
 >       // Any other initialization goes here.
 >     }
-> 
+>
 > Passing in `MyError` as a second argument means that the constructor call to `MyError` won’t show up in the stack trace.
 
-## Implementation Divergence 
+## Implementation Divergence
 
-Unfortunately, the JSC implementation diverges from the V8 one: 
+Unfortunately, the JSC implementation diverges from the V8 one:
 
 - JSC attaches a string valued prop to the object provided, where V8 instead installs their stack-getter function.
 - It uses the JSC stack string format.
 
-I would actually like to specify this like the JSC one. It's simpler. Similarly, the text for the contents of the stack string should probably be something along the lines of 
+I would actually like to specify this like the JSC one. It's simpler. Similarly, the text for the contents of the stack string should probably be something along the lines of
 
 > The contents of the stack string is a textual representation of the [execution context stack](https://tc39.es/ecma262/#execution-context-stack), however the actual format and contents are implemetation defined and should not be relied upon to be identical across implementations.
 
 
 ## Related Work
 
 - The [Error Stacks](https://github.com/tc39/proposal-error-stacks) proposal is largely an orthogonal one to this, but it would provide framework and text to talk about stack strings, as mostly the current spec doesn't really talk about stacks. However, for this proposal I'd argue we don't need to specify the contents of stack strings.
-- The [Error Stack Accessor](https://github.com/tc39/proposal-error-stack-accessor) proposal could be the other route by which the spec starts to talk about stacks. 
+- The [Error Stack Accessor](https://github.com/tc39/proposal-error-stack-accessor) proposal could be the other route by which the spec starts to talk about stacks.
 
 ## History
-- Presented February 2025, and achieved Stage 1 [(slides)](https://docs.google.com/presentation/d/1SFdS9n5JR7Jqz29s7ApvkqDOqOfPW-IaBR2orK828As/mobilepresent?slide=id.p) (notes not yet posted)
+- Presented February 2025, and achieved Stage 1 [notes](https://github.com/tc39/notes/blob/main/meetings/2025-02/february-19.md#errorcapturestacktrace-for-stage-1)

README.md

@@ -1,11 +1,9 @@
 {
   "private": true,
-  "name": "template-for-proposals",
-  "description": "A repository template for ECMAScript proposals.",
+  "name": "proposal-error-capturestacktrace",
+  "description": "ECMAScript Proposal, specs, and reference implementation for Error.captureStackTrace",
   "scripts": {
-    "start": "npm run build-loose -- --watch",
-    "build": "npm run build-loose -- --strict",
-    "build-loose": "node -e 'fs.mkdirSync(\"build\", { recursive: true })' && ecmarkup --load-biblio @tc39/ecma262-biblio --verbose spec.emu build/index.html --lint-spec"
+    "build": "ecmarkup --load-biblio @tc39/ecma262-biblio --verbose spec.emu --assets-dir dist dist/index.html --lint-spec"
   },
   "homepage": "https://github.com/tc39/template-for-proposals#readme",
   "repository": {
@@ -16,8 +14,5 @@
   "devDependencies": {
     "@tc39/ecma262-biblio": "^2.1.2775",
     "ecmarkup": "^20.0.0"
-  },
-  "engines": {
-    "node": ">= 12"
   }
 }