Initial tasks

[bbimber]

Research:

• Familiarize oneself with how to manage an npm monorepo, and packages for repo management
• Research best practices for maintaining/developing npm packages. Are we missing key things from this list?
• Research testing frameworks. We do not have very specialized or niche needs. Something that is widely used, documented, maintained, and robust is ideal. Jest is my default here. It should ideally offer unit-like testing.
• Research frameworks that would allow the developer to actually build and run specific components in the browser in a code-sandbox type of thing. The use-case here would be to provide a minimal, fast, environment for the developer to build something like an extension to a MUI grid, build some kind of form element, etc. Ideally, this framework would allow one to easily create test cases that sync with the development.
• Evaluate code tools like eslint, and determine if there is a newer compelling alternative to eslint.
• Research options to publish npm packages. The code will all be public/open source. The primary criteria is reliability, ease of use, and ability to integrate with github actions.
• Determine best practices for developing on multiple packages at the same time, and coordinating changes/version updates. Document this in a wki or similar in this project.

Implementation:

• Create structure to handle multiple npm packages within this repo
• Establish branch protection, and integration of code standards into PRs.
• Create a basic README that outlines each npm package, dev practices, and deployment practices
• Create test stubs using github actions
• Create structure to publish the packages using github packages or another mechanism
• Consider making a nightly 'latest' release, auto-generated each day.
• Implement eslint or similar across the project
• Implement basic scaffold for a discvr-utils package

We anticipate to begin with these packages:

• discvr-utils: this should hold very generic code, like helper functions, ideally with minimal dependencies.
• discvr-ui-components: Holds standalone UI components that are not too tightly linked to a specific project. This can depend on MUI. One example might be components that extend a MUI select or enhancements to the MUI grid.
• discvr-jbrowse: we should consider migrating some of the code from the existing discvrlabkeymodules/jbrowse LK module into here.

We may eventually also want project-specific repos, such as mgap or mcc.

[hextraza]

Monorepo management: https://turbo.build/repo/docs
Test framework: https://github.com/jestjs/jest
Actions docs: https://docs.github.com/en/actions
Styling framework: https://v4.mui.com/

[bbimber]

This scenario is the one I have the least grasp on how to best handle:

• It must be fairly common for a developer to need to make changes in multiple packages, and to deploy those modified packages locally such if package1 depends on package2, then package1 can load the updated pacakage2 without needing to publish a formal release.
• This is exactly the scenario we will face when managing npm packages maintained in this repo, and when we try to use components from those packages to build LabKey modules. I think one possible option would be for the developer to push an updated package to some kind of local npm registry (e.g., https://medium.com/@debshish.pal/publish-a-npm-package-locally-for-testing-9a00015eb9fd). There might be other better options.

[hextraza]

https://storybook.js.org/ allows us to develop react components in a vacuum, so you can validate that the UI works on mocked data prior to testing it with LabKey. It seems like https://github.com/wclr/yalc is the solution most people recommend for the monorepo->labkey dependency issue.

yalc publishes your package to a local npm registry and temporarily updates your package.json to point at the local versions. the workflow looks something like:

cd path/to/monorepo/component
yalc publish
cd path/to/enlistment/module
yalc add @monorepo-component

// when done with development
yalc remove @monorepo-component
npm i @monorepo-component

and whenever you make a change in the monorepo, you can use yalc push to update the local version. you can manually do all of this with npm link but it's much more error-prone

[hextraza]

The basic idea with this project is that we have a lot of duplicated code/code we want to use in multiple places throughout our LabKey plugins, so we want to pull modules/components out into a standalone repo. This repo will end up containing a set of NPM packages that we can use as dependencies throughout DiscvrLabkeyModules. As such, we need to set up a monorepo management system. I recommend Turborepo. They have good quickstart documentation and create-turbo, which creates a scaffold for this sort of project, akin to create-react-app. We should research if this seems like a reasonable solution and, if so, push a Turborepo workspace that we can add packages to.

[hextraza]

Added a few issues for the research tasks -- we can add the implementation issues once we're certain what that phase of the project will look like

#2
#3
#4
#5
#6

[hextraza]

https://www.labkey.org/Documentation/wiki-page.view?name=devMachine