| 16:14 | <ryzokuken> | is there a "standard" build flow for proposals? |
| 16:16 | <ryzokuken> | for Intl.DurationFormat I went with a in-tree index.html file which simplifies things on one side but on the other it makes it really hard to do anything since every change to the built spec incurs a merge conflict |
| 16:34 | <bakkot> | different people do it different ways. personally I really like ecma262's flow. there's an action on PRs which checks that the build works, and there's a seperate action which runs on commits to main which pushes to gh-pages: https://github.com/tc39/ecma262/blob/main/.github/workflows/deploy.yml |
| 16:36 | <bakkot> | temporal does the same thing but with some random published github action instead of committing a shell script, if you prefer that: https://github.com/tc39/proposal-temporal/blob/bf85d75e95ad5625c30c647d0d12ac32de127931/.github/workflows/deploy.yml |
| 16:36 | <snek> | if you use the template repo |
| 16:37 | <snek> | it has this set up for you already |
| 16:37 | <snek> | https://github.com/tc39/template-for-proposals |
| 16:38 | <bakkot> | the template does not do that |
| 16:38 | <bakkot> | the template pushes to your main branch, which has the merge conflicts problem |
| 16:38 | <bakkot> | personally I dislike committing build artifacts to the main branch, so I do not use the template |
| 16:41 | <snek> | oh i thought it used gh pages |
| 16:45 | <bakkot> | nope |
| 16:47 | <ryzokuken> | the template pushes to your main branch, which has the merge conflicts problem |
| 16:47 | <ryzokuken> | it wastes time and makes me sad |
| 16:48 | <ryzokuken> | we should probably fix the template to do what ecma262 does? |
| 16:48 | <ryzokuken> | with instructions in the README on what settings to change in order to make it work if needed? |
| 17:05 | <bakkot> | my understanding is that ljharb prefers the thing the template does, and he owns the template. i have not felt strongly enough about this issue to create a competing template thus far but if you are inclined to do so, go for it |
| 17:05 | <bakkot> | or maybe ljharb would be open to changing it? |
| 17:05 | <ljharb> | hm? |
| 17:06 | <ljharb> | what merge conflicts problem are you talking about? |
| 17:06 | <ljharb> | the action in the template should automatically rebase and also force push a commit to PRs and main, that updates the built spec, so any merge conflicts shouldn't last |
| 17:11 | <bakkot> | empirically I don't think it does rebase and force push? [at least not when the branch is on a fork, which is the common case] |
| 17:12 | <bakkot> | also I wouldn't want it to; automatically force-pushing to my branch is kind of hostile |
| 17:15 | <Justin Ridgewell> |
|
| 17:16 | <Justin Ridgewell> | I get this constantly |
| 17:17 | <Justin Ridgewell> | I order to fix, I have to build again and git add index.html to continue the rebase on my branch |
| 17:17 | <Justin Ridgewell> | And if there are multiple commits that landed in main, I do it for each because there’s always a merge conflict. |
| 17:18 | <bakkot> | yeah it does not seem to do the rebase: https://github.com/bakkot/template-testing/pull/2 |
| 17:19 | <bakkot> | though also yeah the problem Justin Ridgewell describes is purely local and is also annoying |
| 17:19 | <bakkot> | ljharb: would you be open to switching the template to do the build on a different branch, instead of committing the build artifact? |
| 17:22 | <ryzokuken> | I order to fix, I have to build again and |
| 17:30 | <ljharb> | also I wouldn't want it to; automatically force-pushing to my branch is kind of hostile |
| 17:30 | <ljharb> | but yeah, i hear what yall are saying re local also |
| 17:31 | <ljharb> | i guess we could switch the template. i did it this way on purpose because it's nice to see, on the same sha, the diff of the input along with the output |
| 17:31 | <ljharb> | if someone wants to make a PR to the template updating all the instructions and actions and stuff, that'd be fine |
| 17:37 | <Justin Ridgewell> | I never need to diff the html, though, I only care to see what the final output is. |
| 17:37 | <bakkot> |
I agree with this in general but in practice I am going to be annoyed if I every single time that I commit, push, notice a typo, and re-push, that fails, regardless of whether I have formally given maintainers permission to force-push whenever they want |
| 17:37 | <bakkot> | the ecmarkup output is not currently very optimized for diffs, fwiw |
| 17:37 | <bakkot> | anyway I am happy to make a PR later today if no one else gets to it before me |
| 18:06 | <shu> | is it bad i manually run ecmarkup when i want to update renders of my spec drafts |
| 18:12 | <snek> | yes we're all judging you |
| 18:12 | <snek> | i do that too though |
| 18:20 | <shu> | it's because i don't know how to set up github actions |
| 21:11 | <bakkot> | ljharb: as long as we're tweaking the repo, can we revisit https://github.com/tc39/template-for-proposals/issues/6#issuecomment-343679280 ? |
| 21:12 | <bakkot> | (syntax highlighters don't know about .emu, is my main complaint) |
| 21:12 | <ljharb> | i still think "not .html" is the best choice. i'm not attached to ".emu" at all tho |
| 21:12 | <bakkot> | why not .html? |
| 21:12 | <ljharb> | is there any way to add an html comment in the outputted file that would kick in a syntax highlighter? |
| 21:13 | <ljharb> | because it's not actually HTML; it won't show up properly in a browser |
| 21:13 | <ljharb> | same reason JSX shouldn't be in a .js file :-) |
| 21:14 | <bakkot> | it is actually html |
| 21:14 | <bakkot> | HTML is a very permissive langauge |
| 21:14 | <ljharb> | that it technically is html doesn't change that it's not going to do anything useful in a browser, which is the main use of html |
| 21:14 | <bakkot> | it's true that it won't render correctly but this is true of many html files which don't inline all of their styles and javascript |
| 21:14 | <bakkot> | we still name those files .html |
| 21:15 | <bakkot> | mostly so that we get syntax highlighting |
| 21:15 | <ljharb> | those are still destined for the browser |
| 21:15 | <ljharb> | this one isn't |
| 21:15 | <bakkot> | this one is, there's just going to be a preprocessing step first |
| 21:15 | <bakkot> | I don't think this preprocessing step is meaningfully different than including some JS which defines custom elements |
| 21:16 | <bakkot> | like I could, in principle, write a script you could include in the source file which would make it render correctly |
| 21:16 | <bakkot> | I'm just not going to bother doing this |
| 21:16 | <ljharb> | i think that conceptually it's very different |
| 21:16 | <bakkot> | but I still want syntax highlighting |
| 21:16 | <bakkot> | how so? |
| 21:17 | <bakkot> | and, more to the point, why is that conceptual difference more important than syntax highlighting working? |
| 21:17 | <ljharb> | oh, than custom elements. perhaps that's closer, but that's not a compelling use case to me |
| 21:17 | <ljharb> | i agree syntax highlighting is nice |
| 21:17 | <ljharb> | i'm open to a solution that involves the extension not being ".html" |
| 21:18 | <bakkot> | I don't think there is a solution other than making the extension .html |
| 21:19 | <ljharb> | what happens if <!-- language: html --> is the first line in the file? |
| 21:22 | <bakkot> | nothing in particular happens, most tools do not know about that syntax |
| 21:23 | <bakkot> | the extension is the only thing which is reliably looked at across tools |
| 21:23 | <bakkot> | so we have to choose between reifying the conceptual difference you see or having syntax highlighting supported across tools |
| 21:31 | <shu> | i've always named my spec sources .html? |
| 21:31 | <shu> | where does it not use .html? |
| 21:33 | <bakkot> | https://github.com/tc39/template-for-proposals/blob/main/spec.emu |
| 21:34 | <shu> | ah, the template |
| 21:35 | <shu> | i mean i don't know what to say other than ecma262's is called spec.html, as are all of 402's sources |
| 21:36 | <shu> | if both of the major specs that use ecmarkup do not care about reifying the conceptual difference, it seems like it is not a choice we should make the default for proposal authors |
| 21:57 | <ljharb> | the only reason i didn't change 262's extension a long time ago was git diff/blame/log DX |
| 21:58 | <shu> | isn't that another data point for favoring tooling over conceptual difference here? |
| 21:59 | <ljharb> | the legacy of specific repos? no, i don't think so |
| 22:00 | <shu> | hm git blame has very little to do with the actual tooling benefit being discussed here, true |
| 22:00 | <ljharb> | "syntax highlighting" remains a good point, but that's the only one i've seen so far (still a weighty one) |
| 22:01 | <shu> | i don't really understand what's to be gained to have a different extension |
| 22:01 | <ljharb> | fwiw, vscode has a setting that should enable syntax highlighting: |
| 22:02 | <shu> | of course in isolation it is possible to fix each individual editor |
| 22:02 | <shu> | but that's not really the point? |
| 22:02 | <ljharb> | i know, i'm just exploring options |
| 22:03 | <ljharb> | i wonder if adding *.emu linguist-language=html to .gitattributes would do it |
| 22:03 | <shu> | what does that do? |
| 22:03 | <shu> | i'm pretty sure my editors don't consult .gitattributes? |
| 22:04 | <ljharb> | i dunno, vscode might |
| 22:06 | <bakkot> | linguist is a github-specific thing |
| 22:07 | <bakkot> | vscode might because it's owned by the same company but I don't think other editors will |
| 22:07 | <bakkot> | (I do not use vscode for ecmarkup, personally.) |
| 23:26 | <snek> | yeah i have a setting in my editor config that tells it to treat emu as html |
| 23:27 | <snek> | autocmd BufNewFile,BufRead *.emu set syntax=html |
| 23:27 | <snek> | also one for .bs |
| 23:29 | <shu> | my editor config is an inscrutable artifact frozen in time |