stevedylan.dev / sequoia
A CLI for publishing standard.site documents to ATProto sequoia.pub
standard site lexicon cli publishing
fork atom

Does not work for SSGs that map paths #9

closed opened by heaths.dev

Jekyll maps files like _posts/YYYY-mm-DD-the-title.md to URL paths like /YYYY/mm/DD/the-title.html, but those paths can also be customized. My blog, for example, prefaces the category before the year. I'm sure other SSGs support this as well.

I appreciate some of the frontmatter is needed for publish to function, but you can't conceivably process other SSGs' path mapping. So what about trying to match heuristics?

If you have the source and destination paths for posts e.g., _posts/ vs. _site/, perhaps it's common enough that you can look for "the-title" in file names, stripping off the year like someone did recently for Jekyll.

Alternatively, may sequoia should support a hook that every blog could add to handle their own mapping.

Another idea might be to allow some lightweight templating. With the date parsing for Jekyll, and turning all frontmatter fields into template fields, we might be able to supply a template in sequoia.json e.g., I have a category frontmatter field, so if sequoia picked out the date components, I could do something like:

"{category}/{year}/{month}/{day}/{title}.html"

Though, in this case, the {title} here is the slug - or at least just the part that represents the title.

stevedylan.dev

Thanks for bringing this up! I identified this would be a potential issue when I was fixing a different issue for Hugo. Most SSGs can build a fairly complex slug build out, so the challenge is finding a solution that can work across multiple platforms. I鈥檓 leaning towards something centered around frontmatter since it鈥檚 a common factor with all SSGs.

heaths.dev (author)

I was thinking this morning, what about a source map of sorts? Not aware of any Jekyll plugin but could write one. Know if Hugo et al do?

It鈥檇 be difficult to support complex slugs from systems, but maybe they could be made to contribute to the solution.

stevedylan.dev

Hmm that might work, and I like the idea of offloading that to the SSG engine rather than trying to make Sequoia support everything.

To some extent this is already supported through frontmatter. If someone sets slugField in their sequoia.json then it will ultimately use that as the full slug/path for a post. Then it鈥檚 just a matter of someone making sure their engine populates that frontmatter field.

We could instead have Sequoia read a separate file but that feels a bit like overkill and harder to keep connected with the rest of the system. Open to hear otherwise though!

heaths.dev (author)

Having to set the slug field on every post seems like a non-starter. We set (or use default) path templates so we don't have to do that.

A couple other ideas come to mind that maybe are less costly overall:

  1. Support reading a source path comment in JSON e.g., <!-- source: _posts/foo-bar.md -->. That said, I don't know if people would really want such a matter, but it seems trivial to add a post templates/layout.
  2. You already have some date parsing and read fields, so what if you made a map of all front matter fields along with the date (original format) and constituent parts like year, month, and date (I doubt you'd need to go further, but could). Then sequoia.json could have a "template": ".." field or something that can contain tokens from that map. Since I have a category in my frontmatter, I might set mine to something like /{category}/{year4}/{month2}/{day2}/{pathSlug}.html where the number means the number of digits (or maybe they are all 4- or 2-digit components).

The second should be straight forward to add fields to the lookup map. The only issue of concern would be ideally scrubbing each field such that you can't have an expression. Maybe just an alphanumeric regex check would e enough.

Another idea might be a sequoia command - assuming one is already auth'd - that a template engine could just invoke. Probably going a little more out there, but I could envision writing a jekyll plugin that invokes sequoia (if found on $PATH or whatever) with this verb that takes the source and destination paths that it should have access to. I imagine most SSGs would. A bit more involved and people would have to write plugins, but perhaps sequoia could list some on the web site people could use off the shelf.

stevedylan.dev

Yeah that's a good point. I'm going to give option 2 a try in a PR here and see how it goes, will ping you to test it out if you're up to it! I need to get Jekyll working on my machine / try some of the techniques with Hugo.

stevedylan.dev

Proposed update in PR #23, has all the instructions and the prerelease can be installed with npm -g sequoia@0.5.0-alpha.0!

stevedylan.dev

Tested this personally and seems to work pretty well! It did raise another interesting issue that I will need to open up separately, and that is whether or not to use UTC or local timezone dates.

@heaths.dev When you have time please do give it a try and let me know if the solution satisfies the issue here!

heaths.dev (author)

The pathTemplate works pretty well, but I see what you mean about UTC vs. local time. Some of my posts are wrong. IMO, the internet runs on UTC so I'd go with that. That said, keep in mind there may be offsets. For a time I used to author mine with a 0 offset but got tired of doing the conversion, so just started using local time with ah +8 or +7 hour offset depending on if it was DST or not (ick). Or, provide both e.g., {year} and {yearUTC}, etc.

heaths.dev (author) edited

Created https://tangled.org/stevedylan.dev/sequoia/pulls/24. I still think defaulting to UTC might make more sense and having *Local variants but at least this is in line with Node.js. That said, I put "UTC" at the end so you still have variables that sort neatly and seem, IMO, visually more appealing. But whatever you like best, of course. 馃檪

stevedylan.dev

@heaths.dev I dig it; thank you!! 馃檹 I like the flexibility this gives so we'll go with it for now

sign up or login to add to the discussion
Labels

None yet.

assignee

None yet.

Participants 2
AT URI
at://did:plc:tg3tb5wukiml4xmxml6qm637/sh.tangled.repo.issue/3medrvymgkj22