feat: adding utilities for cards local generation & testing

[nightknighto]

What type of PR is this? (check all applicable)

• 🍕 Feature
• 🐛 Bug Fix
• 📝 Documentation Update
• 🎨 Style
• 🧑‍💻 Code Refactor
• 🔥 Performance Improvements
• ✅ Test
• 🤖 Build
• 🔁 CI
• 📦 Chore (Release)
• ⏩ Revert

Description

• Adds local development script for generating images from a given testing array of usernames, without interacting with the cloud.
• Chose separate scripts to not mess with the main flow of the app used for production and interacting with the cloud.
• Run npm run local-dev:usercards to run the script and generate the images for local testing.

Related Tickets & Documents

fixes #31 & #26

Mobile & Desktop Screenshots/Recordings

Added tests?

• 👍 yes
• 🙅 no, because they aren't needed
• 🙋 no, because I need help

Added to documentation?

• 📜 README.md
• 📓 docs.opensauced.pizza
• 🍕 dev.to/opensauced
• 📕 storybook
• 🙅 no documentation needed

[optional] Are there any post-deployment tasks we need to perform?

[optional] What gif best describes this PR or how it makes you feel?

[github-actions]

PR Compliance Checks

Thank you for your Pull Request! We have run several checks on this pull request in order to make sure it's suitable for merging into this project. The results are listed in the following section.

Watched Files

This pull request modifies specific files that require careful review by the maintainers.

Files Matched

• package.json

[0-vortex]

Couple of small changes required for base nestjs testing practices. How does testing actually work with this new workflow, can you add it to the testing section of the Readme? 🍕

[nightknighto]

@0-vortex Hmm, well it was meant to be a form of manual standalone testing to check the appearance not automated testing.

Didn't have much luck getting jest to acknowledge the e2e test files in /test as well.

[0-vortex]

@0-vortex Hmm, well it was meant to be a form of manual standalone testing to check the appearance not automated testing.

Ok, other good folder ideas for the static output:

• dist
• out
• coverage

[0-vortex]

@0-vortex Hmm, well it was meant to be a form of manual standalone testing to check the appearance not automated testing.

A fix for avoiding the automated testing failures is to return status code 0 on the base test command and implement our own testing command as a separate script - that way we could keep the testing boilerplate code inside the test folder while avoiding CI issues 🍕

[nightknighto]

@0-vortex Hmm, well it was meant to be a form of manual standalone testing to check the appearance not automated testing.

A fix for avoiding the automated testing failures is to return status code 0 on the base test command and implement our own testing command as a separate script - that way we could keep the testing boilerplate code inside the test folder while avoiding CI issues 🍕

Yup added a separate command for running the generation file.

[0-vortex]

Managed to give this a spin locally and imagined making a user card version 2, the resulting SVG is matching the generated image and can be used to pixel perfect the design without very much trial and error, being very close to local development with a NextJS based frontend; because of the pros and cons of vercel/satori the workflow proposed in this PR is close to best of what we can get.

The paths provided by the svg can be inspected in devtools and provide x/y coordinates by default, making it easy to debug and prototype new cards:

Have a couple more minor changes to suggest to make this perfect IMHO:

Let me know if you find this reasonable ❤️

cc @brandonroberts think this PR is solving the blocker and making development bearable, what are your thoughts?

[nightknighto]

@0-vortex The reason I made UserCard.ts and not a unified file for all local dev is so that each different social card can be generated and tested on its own (highlight cards coming up next). This saves time by not generating other unneeded social cards when testing a specific one and making code more manageable. What do you think?

[0-vortex]

@0-vortex The reason I made UserCard.ts and not a unified file for all local dev is so that each different social card can be generated and tested on its own (highlight cards coming up next). This saves time by not generating other unneeded social cards when testing a specific one and making code more manageable. What do you think?

future social cards could pose some unknown requirements for which we could only make assumptions now; don't think the way we split the code should affect the way we run the testing commands or rather, limit ourselves to optimising those via code only; an example here is we could keep it with whatever name as long as it's in test folder, then split the test runner from the social cards or implement a parameter to the testing command like npm run test:local user. In the suggested changes my issue was the "local-dev" folder holding a single file 😅 🍕

[nightknighto]

@0-vortex Alright, no problem 👍
Can you push from your repo or do I need to do those changes in mine and push?

[brandonroberts]

I like the separate npm script command for usercards. We could make a static page with the sample usernames that fetch from the running backend also, but I think its good enough for now.

[nightknighto]

@0-vortex

[0-vortex]

2 small changes are still needed, test command should get renamed too 🍕

[github-actions]

🎉 This PR is included in version 2.1.0-beta.1 🎉

The release is available on:

• GitHub release
• ghcr.io container (@beta dist-tag)

Your semantic-release bot 📦🚀

[github-actions]

🎉 This PR is included in version 2.1.0 🎉

The release is available on:

• GitHub release
• ghcr.io container (@latest dist-tag)

Your semantic-release bot 📦🚀