#Loqi[preview] [jalcine] #1 Add README to project.
#btremShould it be `yarn install` or `yarn install --immutable`?
#btremThe former modifies yarn.lock. As I said earlier, I'm new to yarn, but several web searches indicate that yarn.lock should not be modified after install.
gRegor, gRegorLove_, angelo, ur5us_, tiim, Xin, [marksuth] and [coreagile] joined the channel
#IWDiscordRelay<jacky#7226> It shouldn't, good point. Changing the file by that command is usually rare and I tend to pin dependencies to prevent that too (been burned by bad semver)
#Zegnat`yarn install --frozen-lockfile` is the one for Yarn 1, which is what the site uses according to package.json / btrem, [jacky]
#[jacky]Ah bet, then tbh, use the frozen lockfile for now
#ZegnatCurrent problem seemed to be that we are POSTing a form body, and then try to parse nothing. The patch in the issue asks express to parse the submitted form
#btremAh, sorry, I didn't realize that there are two microformats node parser projects. The site links to a glenjones/microformats.... I didn't even know there was another one.
#[jacky]sknebel: good chance I missed it when I made that site tbh
#btrem[jacky] let me fix that for you: we need to 1) reference the newer parser on mf.io, 2) update node.mf.io to use the newer parser and 3) booty! Arggh!
#btremI have done a bunch of work on microformats.io that I have not yet pushed, because there's an open PR. But I'd be happy to at least update the website.
barnaby joined the channel
#btremOk, I just made half a dozen PRs for microformats.io. Whoever has write access can look them over. Each PR builds on the last one. If something doesn't work for you, let me know. I can rebase the last PR -- the node link correction -- on earlier work if need be.
[benatwork] and gRegor joined the channel
#gRegorbtrem, a lot of the mciroformats.io PRs seem to be doing the same thing multiple times, like changing indentation?
#gRegorThose could probably be condensed. Should probably add an .editorconfig (https://editorconfig.org) if we want to be prescriptive about the whitespace
#gRegore.g. 61 changes code indentation, but 62 seems to include the same indentation fixes again
#btremgRegor: I was trying to avoid the problems I had earlier with conflicts. So I did a bunch of work, each one building on the last. So each successive PR is a ff from the previous one, if that makes sense.
#gRegorI don't think that's going to work? you'll still need to rebase between each one
#btremI did them as separate PRs so you could merge them one at a time, and more clearly see what each separate PR did.
#[schmarty]but yeah unless you are reviewing/merging them in-order it's a bunch of repeated stuff.
#btremHad I squashed them, I think it would have been harder to see the individual changes.
#gRegorI don't mean squashing necessarily, but like if one does indentation, then the next does the same indentation again + changes <div> to <header>
#[schmarty]gRegor: right, because it includes the same history as the first PR.
#gRegorrepeating the indentation fix shouldn't be necessary?
#btremThe first time I did work, I did separate PRs all branched off main. But I ran into problems with conflicts. And I couldn't figure out how to rebase it. So this time, I pushed the first PR, then continued working, then pushed again with a new PR.
#gRegorOk, let me merge 61 and see what 62 looks like then
#btremIt won't repeat it. As [schmarty] said, each successful PR includes the same history. It now appears that I should have done it as I did the first time. Sorry about all this.
#[schmarty]there's no real "right" way to do it when there are overlapping changes like this. my unhelpful retrospective advice is to not change the indentation :}
#btremFWIW, I was going to wait until the first PR was merged before creating the next PR. But then today it was noted that the site had the wrong link to the node parser, so it sort of forced my hand.