search

open-rpc / playground

A place to play around with OpenRPC. https://playground.open-rpc.org
https://playground.open-rpc.org
Apache License 2.0
40 stars 25 forks source link

Consolidate OpenRPC Repositories into `playground` and Ensure Compatibility #607

Open BelfordZ opened 1 month ago

BelfordZ commented 1 month ago

Objective:

Consolidate the following repositories into a single package:

Ensure the combined codebase uses compatible versions of:

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:

Technical Requirements:

Documentation Recommendation:

For documentation, it's recommended to:

zcstarr commented 1 month ago

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 commented 1 month ago

@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':

https://github.com/open-rpc/playground/issues/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.