#microformats 2022-12-14

2022-12-14 UTC
#
Loqi
[preview] [jalcine] #1 Add README to project.
#
btrem
Should it be `yarn install` or `yarn install --immutable`?
#
btrem
The 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
<j​acky#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
#
[jacky]
I'll upgrade it to yarn 2 soon
#
[jacky]
thanks zegnat++ and btrem++
#
Loqi
btrem has 5 karma in this channel over the last year (6 in all channels)
#
[jacky]
zegnat++
#
Loqi
zegnat has 1 karma in this channel over the last year (16 in all channels)
#
[jacky]
I have to admit, I did _not_ realize that I'm basically the maintainer of this project lol
#
Zegnat
You seem to be the only one that has committed to that repo, [jacky]? ;)
#
[jacky]
heh yeah
#
Zegnat
I can have a look at the repo maybe tomorrow. I mostly code for node these days at the day job anyway. I had a quick look at the open issue, possible patch commented: https://github.com/microformats/microformats-parser-website-node/issues/2
#
Loqi
[preview] [btrem] #2 parsing a snippet of html does not seem to be working
#
sknebel
wait that is using the old JS parser, not the newer typescript one?
#
sknebel
or am I misreading that?
#
btrem
I think "maintainer" is a bit of an understatement, since, as Zegnat pointed out, you, [jacky], are the sole contributer!
#
[jacky]
sknebel: it looks like it is >_<
#
[jacky]
I can port this over to the new TS one (just need to find it)
#
Loqi
[preview] [glennjones] microformat-node: Microformats parser for node.js
#
btrem
sknebel: I think it *is* using Typescript. IIRC some of the errors I received had "Typescript" in the text.
#
Zegnat
The TypeScript one already hosts it's own test page IIRC?
#
btrem
I was trying to fix another issue, "querystring@npm..." is deprecated.
#
Zegnat
I dropped querystring in my patch. But I only did the lightest of testing.
#
btrem
Separate from node.microformats.io?
#
btrem
I'm curious to see what you've done. I tried to drop querystring, but the site stopped working. Site error when I pressed the "Parse" button.
#
sknebel
hm, but we dont link it from microformats.io
#
Loqi
[preview] [microformats] microformats-parser: A JavaScript microformats parser for the browser and node.js
#
Zegnat
Current 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
#
[jacky]
sknebel: thanks
#
btrem
sknebel: https://microformats.io/ has links to both http://node.microformats.io/ and the node parser repo. The links are under the "Parsers" heading.
#
sknebel
thats my point, it doesnt link to the new parser
#
[jacky]
so we need to 1) reference the newer parser on mf.io, 2) update node.mf.io to use the newer parser and 3) profit
#
sknebel
yep. at least I thought consensus a while back was to highlight that one
#
sknebel
instead
#
btrem
Ah, 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.
#
btrem
lol not in that order, [jacky]!
#
[jacky]
lol yeah not that way
#
[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!
#
btrem
(My pirate speak is clearly a bit rusty.)
#
btrem
I 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
#
btrem
Ok, 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
#
gRegor
btrem, a lot of the mciroformats.io PRs seem to be doing the same thing multiple times, like changing indentation?
#
gRegor
Those could probably be condensed. Should probably add an .editorconfig (https://editorconfig.org) if we want to be prescriptive about the whitespace
#
gRegor
e.g. 61 changes code indentation, but 62 seems to include the same indentation fixes again
#
btrem
gRegor: 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.
#
gRegor
I don't think that's going to work? you'll still need to rebase between each one
#
btrem
I did them as separate PRs so you could merge them one at a time, and more clearly see what each separate PR did.
#
btrem
(sigh)
#
[schmarty]
as long as they are reviewed and merged first-to-last it should work fine.
#
btrem
I guess I obviously still messed up re: git.
#
btrem
^ what schmarty said is what I was thinking.
#
gRegor
I'll look more closely later, I could be wrong, but it seems odd to make the same change in multiple PRs
#
[schmarty]
(e.g. once the first PR is merged, when you view the second PR github should only show the diffs between the first and second PR)
#
btrem
^ That's what I was hoping.
#
[schmarty]
but yeah unless you are reviewing/merging them in-order it's a bunch of repeated stuff.
#
btrem
Had I squashed them, I think it would have been harder to see the individual changes.
#
gRegor
I 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.
#
gRegor
repeating the indentation fix shouldn't be necessary?
#
btrem
The 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.
#
gRegor
Ok, let me merge 61 and see what 62 looks like then
#
btrem
It 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 :}
#
gRegor
I think I get it now, just a new PR strategy for me :)
#
gRegor
61 is merged and deployed
#
btrem
FWIW, 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.
#
gRegor
And 62 shows no conflicts 🎉
ur5us_ joined the channel