Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refine Build/Release process for all components #571

Open
1 of 2 tasks
jason-capsule42 opened this issue Sep 30, 2024 · 2 comments · May be fixed by #572
Open
1 of 2 tasks

Refine Build/Release process for all components #571

jason-capsule42 opened this issue Sep 30, 2024 · 2 comments · May be fixed by #572
Assignees

Comments

@jason-capsule42
Copy link
Member

jason-capsule42 commented Sep 30, 2024

Please verify the version of wc-generator you have installed

No response

Please describe the work

All Auro repositories need to follow a consistent build and release process. Currently, this process is slightly different from one component to the next.

Task Breakdown

  • Outline current build/release process
  • Determine what the ideal build/release process

Thoughts and opinions

Overall this process is okay but it glosses over the fact that there's almost a dozen build and build:* scripts in the package json that are all very important for each component. This is really hard to understand for me as a new-ish engineer to the Auro space, and seems fairly unmaintainable moving forward.

There's a couple instances of duplicated efforts/processing but overall it's not too bad. The BIGGEST issue I see here is the conditional check for merging to main is only ever run once on main by default. This could cause major headaches managing large changes since there could be many things that remain uncaught until they're already in main.

Finally, the convention in almost every JavaScript packages these days is to have maybe 5 scripts a developer should care about. Again following convention, these are dev, serve/start (for production mode locally), build, test, and lint - optionally a sixth could be typecheck if TypeScript is present and a separate check is desired. Having multiple build scripts can create confusion since a new developer doesn't immediately know which one they need to care about.

Proposals

  • Borealis uses wireit tool to run workflows that have dependencies on multiple package json scripts - https://github.com/google/wireit
  • Leverage upcoming changes to auro-library to seed repositories with "macro" style scripts that automatically handle build steps like generating documentation somehow

Exit criteria

No response

@jason-capsule42 jason-capsule42 added wc-generator Type: CI Changes to CI configuration files and scripts labels Sep 30, 2024
@jason-capsule42 jason-capsule42 linked a pull request Oct 1, 2024 that will close this issue
6 tasks
@chrisfalaska
Copy link
Contributor

I was recently looking at the new Deno 2.0 release (created by Ryan Dahl, the creator of Node.js):

https://docs.deno.com/runtime/getting_started/command_line_interface/

https://www.youtube.com/watch?v=sgXr6iGT71Y

  • TypeScript support out of the box (deno run bypasses the need for a tsconfig)
  • lint subcommand (replace ESLint, etc)
  • format - replaces Prettier, etc
  • Backwards compatibility with NPM/package.json and monorepos (NPM Workspaces)
  • Has its own registry, JSR
  • Stable standard library: https://jsr.io/@std (replaces the need for Jest, Chalk, Lodash, to name a few)

Screenshot 2024-10-01 at 9 25 37 AM

@jason-capsule42
Copy link
Member Author

Test comment

@jason-capsule42 jason-capsule42 removed the Type: CI Changes to CI configuration files and scripts label Oct 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants