jackvincentnz / lab Goto Github PK

https://github.com/bazelbuild/bazel-gazelle

• Generate and cleanup build files

• Fix build files

• Update repositories

• Automation of the above?

• Information in README etc.

The schema types should be generated for use in the java resolvers.

https://github.com/microsoft/TypeScript/wiki/Performance

Once build times drop below 20 mins, investigate adding a remote build cache.

GCP provides a storage solution with a free tier. Another alternative is to use an nginx instance.

Useful info:

• https://docs.bazel.build/versions/main/remote-caching.html
• https://cloud.google.com/free/docs/gcp-free-tier/#storage
• https://github.com/tensorflow/tensorboard/blob/48c0a2d814c755937f5950e251e8071199c99d38/ci/bazelrc#L27-L34

https://github.com/bazelbuild/rules_nodejs/releases

Depends on rules_nodejs updated to Jasmine 4 first. Likely a breaking version.
https://github.com/bazelbuild/rules_nodejs/blob/a416bee9276bee1a7cd1156ef685cb0fa0804691/packages/jasmine/jasmine_runner.js#L119

onComplete() is deprecated.

• Clean up any failures in repo
• Run check in CI
• Add to README and style doc

• overview of commit message linting
• other commit hooks
• why mono repos are helpful
• schematics
• onboarding time
• build time
• test time
• ci
• feedback loops

Things to consider:

• commit message guidelines
• pr process
• build & test etc.
• when to merge

https://github.com/commitizen/cz-cli

• Tinker
• Bubble
• Dynamic
• Therma
• Thermo

Determine how to build and test solution in Github actions.

https://dev.to/brifiction/npm-package-development-with-vite-4jc6

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• chore(deps): update distroless_java docker digest to 97db68b
• chore(deps): update dependency vite to v5.1.6
• chore(deps): update dependency bazel to v7.1.0
• chore(deps): update typescript-eslint monorepo to v7.2.0 (@typescript-eslint/eslint-plugin, @typescript-eslint/parser)
• chore(deps): update storybook monorepo to v8 (major) (@storybook/addon-essentials, @storybook/addon-interactions, @storybook/addon-links, @storybook/blocks, @storybook/react, @storybook/react-vite, storybook)
• 🔐 Create all rate-limited PRs at once 🔐

Errored

These updates encountered an error and will be retried. Click on a checkbox below to force a retry now.

• chore(deps): update dependency @vitejs/plugin-react to v4.2.1

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update dependency @types/dockerode to v3.3.26
• chore(deps): update dependency @types/node to v18.19.23
• chore(deps): update dependency aspect_bazel_lib to v2.5.3
• chore(deps): update react monorepo (@types/react, @types/react-dom)
• fix(deps): update apollo graphql packages (@apollo/client, ghcr.io/apollographql/router)
• chore(deps): update dependency typescript to v5.4.2
• fix(deps): update mantine monorepo to v7.6.2 (@mantine/core, @mantine/hooks)
• chore(deps): update dependency cypress to v13
• fix(deps): update dependency @tabler/icons-react to v3
• Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• chore(deps): update codecov/codecov-action action to v4
• chore(deps): update dependency @types/node to v20

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

People can pass --no-verify to commits to avoid commit checks. The same checks should be run again by CI.

New applications should be created in /projects with common defaults.

E.g. as strict as possible, with routing etc.

E.g using something like apollo cache, or even suggesting we shouldn't do this and instead load all of the page state all in one query?

A common example is a list of objects, and then a details panel that allows editing of the values of the items in the list. How to manage updates to the list when the values are changed in the form in the details?

Ideally the details feature doesn't even know that there are other features that depend on the same state.

Add to mono repo features.

Draw out diagram of the optimized development workflow from onboarding through to production delivery

• Optimized environment setup
• Optimized getting started building / testing
• Optimized running
• Optimized feedback loops (build, test, commit, pr, merge)
• Optimized shipping delivery to production
• What feedback occurs at what stages of build
• How we mitigate issues getting into the trunk

etc.

ts_project should be wrapped to supply common inputs for node/web ts projects, and isolate solution code from change in rules_nodejs

• Why
• Method
• What coverage is reasonable for this repo
• Improvements

https://prettier.io/docs/en/install.html
https://prettier.io/docs/en/editors.html

• Add README and onboarding information for editor setup etc.
• Add prettier check to CI, along with linting in general?
• Run prettier on a git hook
• Review other information in the install steps above.

Ensure that rebased commits with lint/formatting errors are caught in CI.

E.g. cra that is committed and then fixed in subsequent commits in single PR, should it fail for the initial commit or if the lint + style is fine for the total PR diff then we are ok?

Switch to ESLint.

Is it possible, and worth it to avoid having to yarn on the solution root?

In place of this can bazel build //... be used instead to install yarn and then make it available to all of the build tooling?

E.g. can commit hooks still work this way? Can they use bazel installed npm packages etc.?

Angular launch config:

{
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "name": "ng serve",
      "type": "pwa-chrome",
      "request": "launch",
      "preLaunchTask": "npm: start",
      "url": "http://localhost:4200/"
    },
    {
      "name": "ng test",
      "type": "chrome",
      "request": "launch",
      "preLaunchTask": "npm: test",
      "url": "http://localhost:9876/debug.html"
    }
  ]
}

Angular task config:

{
  // For more information, visit: https://go.microsoft.com/fwlink/?LinkId=733558
  "version": "2.0.0",
  "tasks": [
    {
      "type": "npm",
      "script": "start",
      "isBackground": true,
      "problemMatcher": {
        "owner": "typescript",
        "pattern": "$tsc",
        "background": {
          "activeOnStart": true,
          "beginsPattern": {
            "regexp": "(.*?)"
          },
          "endsPattern": {
            "regexp": "bundle generation complete"
          }
        }
      }
    },
    {
      "type": "npm",
      "script": "test",
      "isBackground": true,
      "problemMatcher": {
        "owner": "typescript",
        "pattern": "$tsc",
        "background": {
          "activeOnStart": true,
          "beginsPattern": {
            "regexp": "(.*?)"
          },
          "endsPattern": {
            "regexp": "bundle generation complete"
          }
        }
      }
    }
  ]
}

• App specific ones
• Module vs CJS
  • Switch everything to Module

https://www.npmjs.com/package/eslint-config-react-app

It should be impossible to commit files that are not meeting the existing style of the repo.

• Add prettier
• Run linting and formatting on commit

Currently there is a weird circle from the graphql documents, out to the generation dir, back to the ts compilation in the lib.

This could be resolved by generated the graphql lib within the fe_library instead.

• Ensure we are including sources which we want to know coverage for, even if there are no tests at all for those sources.
• Include FE sources in coverage outputs.
• Optimize build time for coverage generation, ensuring that production outputs don't include coverage instrumentation.

E.g.

Avoiding import { expect, it, render, screen } from "../../../../../tools/bazel/vitest/test-utils";

This could be achieved by building a (very) small package for this test tooling.