profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/GeoffreyBooth/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Geoffrey Booth GeoffreyBooth Disney Los Angeles, CA https://geoffreybooth.com Principal software engineer. Full-stack web developer and team lead. Core collaborator of Node.js. Maintainer of CoffeeScript. Imagineer. Father.

aponxi/sublime-better-coffeescript 438

Syntax highlighting and checking, commands, shortcuts, snippets, watched compilation and more.

coffeescript6/discuss 165

A place to discuss the future of CoffeeScript

disney/dockerized-opentext-media-management 12

Scripts and configuration files for running OpenText Media Management in Docker

GeoffreyBooth/browser-equivalence-edge-case 4

A demonstration of code that executes differently in Node and browsers

GeoffreyBooth/coffeescript 4

Unfancy JavaScript

DerekNonGeneric/loader339 1

ES Module Loader Prototype — APM

DerekNonGeneric/web-context-js 1

Naïve userland JS implementation of HTML specifier restriction and web browser “window” as “globalThis”

GeoffreyBooth/dual-package-hazard 1

Example illustrating the hazard posed by dual CommonJS/ES module packages

akfish/CommonMark 0

CommonMark spec, with reference implementations in C and JavaScript

PullRequestReviewEvent

delete branch GeoffreyBooth/node

delete branch : geoffrey-update-email

delete time in 2 days

pull request commentjashkenas/coffeescript

ci: Check that build steps didn’t change any files

Awesome, thanks!

edemaine

comment created time in 2 days

push eventjashkenas/coffeescript

Erik Demaine

commit sha ff13d856259c7d44a19e908648fc5409dcc80fe9

ci: Check that build steps didn’t change any files (#5373)

view details

push time in 2 days

PR merged jashkenas/coffeescript

ci: Check that build steps didn’t change any files

@GeoffreyBooth wrote:

We should add a CI step that rebuilds everything and then checks that there’s nothing different from the last git commit (which, if there was a difference, would mean that the author forgot to rebuild and commit one of the outputs).

This PR adds this CI step, which turned out to be easy, because all the building was already getting tested.

For some reason, the browser build is different on Node 6.x and 8.x (in my CI testing). So we don't run the diff in those cases, which seems OK to me.

+3 -0

4 comments

1 changed file

edemaine

pr closed time in 2 days

pull request commentjashkenas/coffeescript

ci: Check that build steps didn't change any files

Or am I missing a use-case for running the build and diffs even when the tests fail?

I’m trying to prevent what happened with https://github.com/jashkenas/coffeescript/pull/5324, where we merged in without running cake build:browser and so when I added Node 16 to CI, the tests for 16 were failing because they used the browser build which hadn’t been updated.

I think what you have is probably fine; maybe it’s not actually necessary because the tests themselves will catch it? But yeah somehow we were able to get a passing CI in https://github.com/jashkenas/coffeescript/pull/5324 even though the browser output hadn’t been rebuilt. In https://github.com/jashkenas/coffeescript/pull/5372 I both added Node 16 and rebuilt the browser compiler, and it was the latter that got CI passing again.

edemaine

comment created time in 2 days

pull request commentjashkenas/coffeescript

ci: Check that build steps didn't change any files

Awesome! Yeah, Node 6 and 8 (and even 10) have been EOL for so long now that maybe we should take them out. I was thinking of getting the next release out first though before considering that.

Have you tested this? Like by pushing a branch (or opening a PR, if pushing a branch isn’t enough) where you change something that breaks tests, and don’t run cake:build or cake build:browser, to see if this catches it?

edemaine

comment created time in 2 days

issue commentnodejs/loaders

Node.js Loaders Team Meeting 2021-09-15

@arcanis, @cspotcode, @jonaskello What’s your availability next week, and generally?

I’m working on getting access to be able to adjust the meetings. I’m thinking that we can have an ad hoc meeting next week whenever those involved in #26 are available, and then on the following week we can have our regular meeting as usual (such as at the Wed 9 pm UTC time unless there’s a better time).

mhdawson

comment created time in 2 days

pull request commentnodejs/loaders

2021-09-15 notes

In the future please leave it open for a few days in case anyone has notes.

GeoffreyBooth

comment created time in 3 days

delete branch nodejs/loaders

delete branch : 2021-09-15-notes

delete time in 3 days

PR opened nodejs/loaders

2021-09-15 notes documentation

Closes #27

+26 -0

0 comment

1 changed file

pr created time in 3 days

create barnchnodejs/loaders

branch : 2021-09-15-notes

created branch time in 3 days

issue commentnodejs/loaders

Node.js Loaders Team Meeting 2021-09-15

@DerekNonGeneric you indicated above that you can attend, and I heard from Jacob and Bradley that they can also both attend, so that’s four people right there. @arcanis’s topics are unrelated to chaining, so we can discuss them at the next meeting where they can attend. I think that’s better than skipping this week entirely.

mhdawson

comment created time in 3 days

PullRequestReviewEvent

issue commentnodejs/loaders

Node.js Loaders Team Meeting 2021-09-17

I think I’ll hold a meeting today at 2 pm PT / 5 pm ET / 9 pm UTC / 11 pm CEDT and whoever can attend is welcome. At the very least @JakobJingleheimer and I need to discuss next steps for chaining, so maybe that’s all that’ll happen. And we can schedule a separate meeting to discuss the utility functions stuff.

mhdawson

comment created time in 3 days

issue commentnodejs/loaders

Feature request: Fine grained API to implement loaders that can do what --experimental-specifier-resolution does and more

@guybedford, if I can loop you in, what do you think of https://github.com/nodejs/loaders/issues/26#issuecomment-918413522? Since you wrote many of those functions and designed the overall ESM resolution algorithm.

jonaskello

comment created time in 3 days

pull request commentjashkenas/coffeescript

Support top-level await

Thanks. I’ll cut a new release branch soon.

edemaine

comment created time in 3 days

push eventjashkenas/coffeescript

Erik Demaine

commit sha c4f1fe7132340c9bfea509e9dcb87eab3910197e

Support top-level await (#5371) * Support top-level await * Remove code duplication * Avoid use of trimEnd so tests pass in old Node * Proposed rewrite of tests * startsWith tests; revert eqJS * build:browser

view details

push time in 3 days

PR merged jashkenas/coffeescript

Support top-level await

@GeoffreyBooth mentioned that CoffeeScript is missing support for top-level await. This PR adds that support.

Mostly this involves doing fewer checks for invalidity. The only hard part is when the code is wrapped in a top-level IFFE, where we need to detect whether that wrapper should be marked async.

Fixes #5354 (request from Deno side).

The REPL already supported top-level await by explicit wrapping in an async function closure. I think it's best to keep that code, because older versions of Node don't support top-level await.

+45 -19

4 comments

8 changed files

edemaine

pr closed time in 3 days

issue closedjashkenas/coffeescript

deno can await outside function, how to remove " error: await can only occur inside functions "

deno can await outside function, how to remove " error: await can only occur inside functions "

closed time in 3 days

gcxfd

push eventjashkenas/coffeescript

Erik Demaine

commit sha b0946c3c60ae97ea72f5ff7cb0e53b57eb8496a6

Fix documentation links to try/catch section (#5349) * Fix documentation links to try/catch section Consistently use `#try-catch` for the section (and `#try` for the demo) * Fix documentation source

view details

push time in 3 days

PR merged jashkenas/coffeescript

Fix documentation links to try/catch section
  • Consistently use #try-catch for the section (and #try for the demo).
  • The table of contents actually lacked this entry (and labeled switch to include it), making it hard to find.
  • And another section linked to #try which went to the wrong place.
  • This has been an issue for a long time, so I fixed both v1 and v2 docs.
+11 -8

4 comments

5 changed files

edemaine

pr closed time in 3 days

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentjashkenas/coffeescript

Fix documentation links to try/catch section

Just bumped into this again. Let me know if there’s anything else that needs to be done for this to be merged.

Please just rebase or merge master in so that we get a passing CI.

edemaine

comment created time in 4 days

pull request commentjashkenas/coffeescript

Support top-level await

Got CI fixed. Can you please rebase off of master or merge master into your branch? That should trigger a new test run that’ll include Node 16.

FYI besides rebuilding the regular compiler we also need to build the browser compiler (cake build:browser). We should add a CI step that rebuilds everything and then checks that there’s nothing different from the last git commit (which, if there was a difference, would mean that the author forgot to rebuild and commit one of the outputs).

edemaine

comment created time in 4 days

push eventjashkenas/coffeescript

Geoffrey Booth

commit sha b90bc2459a6f0e45a26e9d34b16f526b2aaabf29

Add Node 16 to CI (#5372)

view details

push time in 4 days

delete branch GeoffreyBooth/coffeescript

delete branch : node-16

delete time in 4 days

PR merged jashkenas/coffeescript

Add Node 16 to CI

<!-- Before making a PR please make sure to read our contributing guidelines: https://coffeescript.org/#contributing

For issue references: Add a comma-separated list of a closing word followed by the ticket number fixed by the PR. It should be underlined in the preview if done correctly.

All new features require tests. All but the most trivial bug fixes should also have new or updated tests.

Ensure that all new code you add to the compiler can be run in the minimum version of Node listed in package.json. New tests can require newer Node runtimes, but you may need to ensure that such tests only run in supported runtimes; see Cakefile for examples of how to filter out certain tests in runtimes that don’t support them.

Please follow the code style of the rest of the CoffeeScript codebase. Write comments in complete sentences using Markdown, as the comments become the annotated source. For tests proving a bug is fixed, please mention the issue number in the test description (see examples in the codebase).

Describe your changes below in as much detail as possible. -->

+11 -11

0 comment

5 changed files

GeoffreyBooth

pr closed time in 4 days

push eventdisney/meteor-base

Iván Cabrera

commit sha 4c8e204d218ad5bc9e895d635911b99864912ee0

Add 2.4 (#88)

view details

push time in 4 days