Executing on new Code Snippet system

# Code Snippet System Implementation Details This document provides a detailed overview of the implementation strategy for the code snippet system. It serves as a follow-up to the discussion initiated in [Issue #1067](https://github.com/TBD54566975/developer.tbd.website/issues/1067) and aims to clarify the next steps for implementation. ## Objective The primary goal is to enhance the efficiency and reliability of our code snippet system. By automating the process and integrating robust testing, we aim to streamline the development workflow and ensure high-quality documentation. ## Implementation Details ### 1. Unit Testing Framework Selection To ensure the quality and reliability of our code snippets, selecting an appropriate unit testing framework is crucial. - **JavaScript**: We plan to use **Jest** as it's widely adopted and offers comprehensive testing features. - **Kotlin & Swift**: We will consult with the Web5 team to determine the most suitable frameworks used in their current workflow. ### 2. Integration of Existing Code Snippets Leveraging existing resources will expedite the development process and maintain consistency. - **Source**: We will import code snippets from the Web5/Tbdex SDKs. - **Review Process**: - Assess the current unit tests available in these SDKs. - Collaborate with the Developer Relations (Dev Rel) team to ensure the tests align with their standards and requirements. ### 3. Code Snippet Extraction and Transclusion To maintain up-to-date and accurate documentation, we will implement an "Extract and Transclude" system. - **Tool**: We will utilize [Bluehawk](https://mongodb-university.github.io/Bluehawk/), a CLI tool designed for such tasks. - **Integration**: To accommodate updates from the Web5 team, we will set up GitHub Actions that trigger Bluehawk commands post-update. **Note**: The focus here is on testing SDK code snippets. Tutorial content will be addressed separately to cater to its unique requirements. ### 4. Automation Goal Our ultimate aim is to automate the snippet management process as much as feasible. - **Reusability**: By borrowing and adapting code snippets already crafted by the Open Source Engineering (OSE), we can enhance efficiency and consistency across our documentation. - **Collaboration**: Engaging with teams who have prior experience in similar tasks will provide valuable insights and potentially speed up the implementation process. ## Next Steps 1. **Framework Decision**: Finalize the unit testing frameworks for Kotlin and Swift after consultation with the Web5 team. 2. **Integration Plan**: Develop a detailed plan for integrating existing code snippets, including a review and adaptation process. 3. **Automation Strategy**: Outline a comprehensive strategy for automating the extraction and transclusion of code snippets using Bluehawk and GitHub Actions. 4. **Collaboration**: Schedule meetings with the Dev Rel team and other stakeholders to align our strategies and gather additional insights. By meticulously planning and executing these steps, we aim to create a robust and efficient code snippet system that enhances our documentation and supports our development community. ## Workflow (first pass) - OSE does a release - All code snippets are already tested and passing on their end - We use GitHub Actions to import their already-made tests (theoretical right now) - DevRel runs BlueHawk CLI to create code snippets - Code snippets get imported to appropriate documentation ## Workflow (maintenance) - OSE does a release - DevRel ensures BlueHawk CLI is ran to regenerate code snippets (maybe handled via GitHub actions) - No further action needed ## Potential Obstacles - Are the tests that OSE writes up to Dev Rel standards? - If not, then Dev Rel will have to continue writing, testing, and maintaing code snippets manually (can switch to BlueHawk anyway for code snippets) - Bluehawk is intended to be used in the same monorepo as the docs. We'll have to figure out a good way to import current code snippets by OSE ## Impact for DevRel * Accelerates our path to multi-language support in tested code snippets, by using existing working external library * Code snippets would live as dependencies, not directly in the dev site source * Pro - Snippet changes, living upstream from the dev site, would come for free during upgrades. * Pro - Tested as part of upstream PR and release processes. * Con - Updating code snippets on the dev site would require publishing a new release of the upstream project where the snippet live * DevRel would be working more closely with upstream ENG projects to ensure the test suites have code in ## Prototype - How to use BlueHawk to embed something from the test suite (from a dependency) - How to use BlueHawk to embed something in an example (from something locally)