feat: add build step for consistent artifact generation#2
feat: add build step for consistent artifact generation#2jsejcksn wants to merge 4 commits intoreggi:masterfrom
Conversation
|
Hah! @jsejcksn thanks so much for this, and thanks for your help over on stack-overflow! Thoughts:
I am struggling with the integrity of the fortunes. As in adding new ones that I don't physically have in my possession. I feel like the fort knox of fortune cookies, as in every one in the repo is backed by a piece of paper. Gold as to fortune paper, as fortune is to cash? Or when the dollar was backed by gold. Anyway. I'd be down to add a CSV for third-party contributions but with some real-world backing, perhaps a photo on twitter or instagram with a real non-bot user? Or mail me your fortunes (lol)! What I'm afraid of is people making PR's of nonsense fortunes they've heard about online cluttering this repo up. Here's an example of one I found that is authored that way: |
|
You definitely found some good typos! But i'd like to keep the ones as they are if they are written as-is. |
|
@reggi Thanks for sharing those thoughts and explaining more.
Reading this was simultaneously somewhat expected, yet still a surprise to me.
I actually didn't contribute any: During the cleanup, I noticed that the JSON file had some additional fortunes appended to the end of the list that weren't in the text file, and I simply copied them to the text file.
Thanks for your welcoming suggestion. I think that can be addressed in a separate PR if you want to include it — especially if it involves another branch. I shared it here simply to give you insight into my process (and to share an artifact of that in case you found it useful). Re: the Google spreadsheet link: I couldn't access it when I tried. Perhaps you can double-check that its access level is set to public if you intended for me and other viewers of this PR to be able to view it. Re: no. 2 through no. 5 and the rest of your message: When I found the repo, the personal nature of the collection wasn't clear to me — I didn't realize that it was intended as a digital copy of the verbatim strings of the messages from your personal preservation, and that you "[felt] like the fort knox of fortune cookies, as in every one in the repo is backed by a piece of paper." I also didn't assume that you mis-typed anything when transcribing. And with those in mind, I hope it makes sense to hear that I wouldn't have even begun the PR had I understood this aspect. Since this is very personal to you, I completely understand wanting to maintain the accuracy of the details in that way. I think somehow including digital evidence (like those photos) in a directory of the repo will help communicate the nature of what you described. So — that said — are there parts of the PR that you want? My effort in this was to help make it more usable by others and easier for you to maintain: just keep updating the text file and generate the other artifacts. Toward the former concern: if you want to keep duplicates, perhaps that part of the build step can be omitted and documented as an exported function that can be used by consumers who don't want the duplicates. Do you want to just update the text file and regenerate the other file formats, keeping the build script, ESM, etc.? How would you like for this PR to proceed? |
|
Ah! Ok good learnings here. Can you split this PR into two one with just the I am worried about dropping I agree with removing dupes for release I can add a build step for that. |
|
I'll try setting up a github action to build the files and publish, so no need to include the built files here. |
Of course! But before I do that, I'd like to respond to some of what you said:
Are you trying to support unsupported versions of Node? All versions of Node that aren't already past end-of-life have support for ESM. CommonJS was very useful when there was no standardized module system in JavaScript, but now it's a relic. If you are committed to supporting those ancient versions of Node (and a non-standard module system), there's the package entry points feature.
Importing of JSON modules in ESM requires the use of an import assertion which is a stage 3 proposal, (it's considered experimental until finalized because there's a [microscopically small] possibility that the syntax/behavior could still change before then), so I don't recommend providing a JSON file as the entrypoint for ESM consumers right now. Beyond any potential stability concerns, it would require consumers to know that your entrypoint is JSON ahead of time and to actually use the import assertion syntax when importing your (JSON) package: import fortunes from 'fortune-cookie' assert {type: 'json'};IMO, this is suboptimal DX for the consumer because of the increased cognitive load, and I recommend providing a JS module entrypoint that handles this for them "behind the scenes" — see my comments in
I'm not sure if you meant that you are thinking about removing the generated files from the repo. If so, here's a (perhaps unconventional) opinion for perspective: I think there's great value in keeping those build artifacts in the repo (in a directory or even if in a different branch from the source): not everyone has the same experience level in tooling (so not everyone can build — and, even if they could, it's such a chore when you just need a single file), so having equal access to static artifacts in the same way as static source is a win for accessibility. It's very annoying to me when I need access to some built artifact in an npm package (e.g. a generated wasm module in a non-Node environment like Deno, etc.) and I can't get it from GitHub because it doesn't exist in the repo (or it's only included as one asset in a binary tarball/zip archive in a release), so I have to either download/extract/cleanup (which is even more cumbersome if it's needed as a resource provided by an automated network request) or go find it at some third-party CDN (e.g. unpkg), relying on its availability. (end of rant) So...
|
6e39987 to
df3d9b8
Compare
|
@reggi While awaiting your reply, I went ahead and rebased this PR: now it only addresses the build step and generation of artifacts (the other file formats besides the source text file — ES module, JSON, Markdown). I also added JSDoc type annotations in the build script during the refactor, and now it only deduplicates the fortunes for the generated artifacts and not the text source (per our discussion above). Hopefully that helps reduce complexity here by separating concerns — and if you decide to consider the other changes, those can be handled in separate PRs. |
















Hi @reggi
I like that you collected these fortune messages and shared them! I always find them fun or funny when I get one.
I noticed a typo while reading them and started to create a PR for a single line fix, but then I kept reading and noticed some more, and saw an opportunity to improve the overall consistency of the collection with a simple build step to generate the other file formats from the text file.
The corrections I made are all overtly obvious grammatical/syntactical ones. I didn't worry about stylistic things or misplaced commas, etc. I know that part of the allure of fortune cookie messages can be the occasional bad translation or strange phrasing, and I generally avoided engaging those cases as well. In case it's not clear what I meant by the previous sentence, here's an example from your collection with a link to someone's take/explanation:
https://followingfunny.com/2011/10/10/fortune/
In addition to generating other file formats, the build script ensures additional consistency in things like file names, whitespace, a simple deduplication algorithm (which removed several duplicates), etc. You can read the comments in the script to get precise clarity.
Re: ESM: Here's a link to the current LTS version of the Node documentation that addresses JSON import assertions: https://nodejs.org/docs/latest-v16.x/api/esm.html#json-modules
Final notes:
Implementing consistent file naming is a breaking change (as is switching to ESM), and I didn't increment the package version in this PR. I just wanted to mention that in case you decide to accept it.
I also wrote this simple, self-contained React app to review the quotes as I was working on the PR — it works without any build step, using just a local static file http server (I used this one):
viewer.htmlI hope you find this PR useful. Thanks again for sharing your collection.