| 00:09 | <Bakkot> | gibson042: https://github.com/tc39/ecma262/commit/fd89c38c38bacc2fc0369630d06995bbe8f15cce should probably have been its own PR |
| 00:11 | <Bakkot> | both because it's unrelated to the actual change in #2021 and because when you add nontrivial changes to an existing PR after it's been reviewed those changes might get merged without review, as just happened |
| 01:00 | <MylesBorins> | ljharb done |
| 01:00 | <ljharb> | thanks! |
| 01:02 | <ljharb> | Bakkot: happy to revert that one commit (i kept them separate) and it can come back as a separate PR, if you'd prefer |
| 01:03 | <Bakkot> | ljharb it looks fine; I don't think it needs reverting. I'd've just preferred to review it before it was landed, is all |
| 01:04 | <Bakkot> | ideally in its own PR |
| 01:04 | <ljharb> | noted, i'll look out for that sort of thing in the future |
| 01:50 | <Bakkot> | ljharb btw it looks like the most recent commit on https://github.com/tc39/template-for-proposals/commits/main failed, probably because of the master->main rename |
| 01:50 | <Bakkot> | ljharb also I am confused by the claim "ecmarkup uses HTML syntax, but is not HTML" |
| 01:50 | <Bakkot> | how is it not HTML? |
| 01:51 | <ljharb> | thanks, i'll take a look |
| 01:51 | <ljharb> | i think it might be the protected branch thing, which i'd enabled |
| 01:51 | <Bakkot> | ahh, yeah, probably that |
| 01:51 | <Bakkot> | protected branches are good, it'd be a shame if we can't use them |
| 01:52 | <ljharb> | so i think it's because i pushed directly to the default branch |
| 01:52 | <ljharb> | normally, the action kicks off on PRs, and so it doesn't need to update anything once merged |
| 01:52 | <ljharb> | anyways re the ecmarkup thing, it's not html because it can't be rendered in a web browser as is, and it's not valid html? not sure this is really worth getting into a debate about tho |
| 01:52 | <ljharb> | name the file whatever you want ofc |
| 01:54 | <Bakkot> | it is valid HTML and can be rendered in a web browser as-is, that's the bit I'm confused about |
| 01:56 | <Bakkot> | but yeah I don't much care |
| 01:56 | <ljharb> | <emu-alg> isn't a valid html element afaik |
| 01:56 | <ljharb> | re the template PR, we don't want `--strict` with `--watch`? |
| 01:56 | <Bakkot> | the notion of what is a valid element changed significantly with the introduction of web components |
| 01:56 | <Bakkot> | re: pr, I think not? I would assume if someone is doing --watch they just want to see the rendered output |
| 01:57 | <Bakkot> | and can worry about fixing errors later |
| 01:57 | <Bakkot> | also it's not clear what it would even mean; do you abort the watch job? |
| 01:57 | <Bakkot> | actually yeah I made it so ecmarkup won't let you combine them, for that reason: https://github.com/tc39/ecmarkup/blob/0a0d7b6b9028c5e90f20302e8285602258681f70/src/cli.ts#L22-L25 |
| 01:58 | <ljharb> | i'd want the job to continue but all strict errors to log, just like every test framework does in watch mode |
| 01:58 | <ljharb> | (i think web components aren't valid until you have JS to define them tho; and we're not defining all our emu elements) |
| 01:58 | <Bakkot> | ahh, they log whether or not you pass the flag |
| 01:58 | <ljharb> | oh |
| 01:58 | <ljharb> | so `--strict` is only about the exit behavior |
| 01:58 | <Bakkot> | --strict just makes them fail the build |
| 01:58 | <ljharb> | k |
| 01:58 | <ljharb> | makes sense |
| 01:58 | <Bakkot> | well, also prevents the file from getting written, because I am opposed to writing files on non-zero exit code |
| 01:59 | <Bakkot> | re: web components, I guess that hinges on what you mean by "valid" |
| 02:00 | <ljharb> | fair |