Consolidate OpenRPC Repositories into playground and Ensure Compatibility

[BelfordZ]

Objective:

Consolidate the following repositories into a single package:

• open-rpc/inspector
• open-rpc/logs-react
• open-rpc/playground

Ensure the combined codebase uses compatible versions of:

• Material UI
• React
• Node.js

The goal is to make the project run again with less maintenance required and maintain compatibility across all dependencies.

---

Scope of Work:

1. Single Package Setup:

   • Consolidate the code from logs-react and inspector into playground such that all repositories become a single package.
   • Based on the current structures (inspector, logs-react, playground), recommend using a folder structure like this:
     • src/common: For shared utilities and components across the three codebases.
     • src/inspector: For inspector-specific code.
     • src/logs: For logs-react specific code.
     • src/playground: For code specific to the playground functionality.
   • Ensure there is only one package.json file managing all dependencies.

2. Dependency Upgrades:

   • Make a recommendation for versions of Material UI, React, and Node.js that ensure compatibility across the combined repositories.
   • Important: The goal is to not spend time determining these versions manually, so either provide a good recommendation or make it clear that the versions should be handled automatically during the update.
   • Upgrade Monaco editor and other dependencies if necessary for compatibility with the upgraded libraries.
   • Ensure that the upgraded components work together without breaking existing functionality.

3. Refactor & Fixes:

   • Refactor only code that breaks due to dependency updates, especially focusing on Material UI and Monaco editor compatibility.
   • Stick to immediate concerns raised by the upgrading of dependencies rather than performing extensive refactors.

4. Monaco Editor Setup:

   • Use a React package that simplifies integration with Monaco editor, ensuring it doesn’t complicate the build step but remains reliable and fairly performant. One recommendation could be @monaco-editor/react.

5. Functional Testing:

   • Ensure that the Monaco editor is functional and that updates made in the editor are reflected in the right-hand side (docs view).
   • Ensure that the inspector pops open when the "try it" button is clicked.
   • Use https://mock.open-rpc.org as a test subject for these functionalities.
   • Be creative when coming up with manual test criteria to cover the main functionalities.

6. Testing:

   • Preserve the existing tests in playground. No new tests are required.
   • There are no existing tests in logs-react or inspector. If additional tests help complete the work, feel free to add them, but new tests are not expected.

7. Bugs:

   • Cross-reference any bugs found with the current production playground (https://playground.open-rpc.org). Fix any new bugs introduced during the consolidation/upgrade, but for existing bugs, simply raise an issue.

---

Deliverables:

• A single package hosted on GitHub containing the merged repositories (playground, logs-react, inspector).
• A single package.json file with updated and compatible versions of dependencies (Material UI, React, Node.js).
• Refactored code for compatibility with updated dependencies.
• A manual testing report demonstrating the functional areas described (Monaco editor, inspector).

---

Technical Requirements:

• Node.js (latest stable that is compatible)
• React (latest stable compatible with Material UI)
• Material UI (latest stable compatible)
• Monaco editor (updated if necessary)

---

Documentation Recommendation:

For documentation, it's recommended to:

• Provide a migration guide detailing the consolidation process, folder structure, and key refactors.
• Document any major dependency updates and breaking changes (especially for Material UI and Monaco editor).
• Include usage instructions for testing the key functionalities (Monaco editor, inspector) with https://mock.open-rpc.org.
• Keep the documentation concise, focusing on high-level changes and compatibility considerations.

[zcstarr]

Why not maybe a monorepo with shared components, like with workspaces, then we get all benefits and we don't have to pull in all the deps for all contexts?

[BelfordZ]

@zcstarr Im not opposed to going 'proper' monorepo. @shanejonas mentioned we should try turborepo. Im down to give it a shot here. This is what chat gpt helped me come up with as alternative 'work description':

#608

I think we could stick with semantic release, it might save us a bit of time in the short term (we have typings plugin that is a sem-rel plugin... not ideal anyway you look at it) ... but this could also be a better forcing function to fix that.