Add recipes for just

[adierkens]

just has come about as one of the more popular ways of organizing project specific scripts. Given the multi-language and hard-to-find nature of bazel targets, this gives us a clean way of saving and reusing scripts for users.

> just -l                                                                                                                                                                

Available recipes:
    build-all       # Build all targets in the project
    build-core      # Build all core JS/TS files
    build-js        # Build all JS/TS files
    dev-ios         # Generate and open the xcodeproj for Player
    lint-js         # Lint all JS/TS files
    mvn-install     # Install all generated artifacts into the system .m2 repository
    maven-install   # alias for `mvn-install`
    start-docs      # Run a dev server of the main docs page
    start-ios-demo  # Build and run the iOS demo app in a simulator
    start-storybook # Run a dev server of storybook
    test-all        # Test targets in the project
    test-core       # Test all core JS/TS files
    test-js         # Test all JS/TS files

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.94%. Comparing base (7e8ca9c) to head (f8e3f88).
Report is 155 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #468   +/-   ##
=======================================
  Coverage   91.94%   91.94%           
=======================================
  Files         340      340           
  Lines       26838    26838           
  Branches     1946     1946           
=======================================
+ Hits        24675    24677    +2     
+ Misses       2149     2147    -2     
  Partials       14       14           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sugarmanz]

My 2c, we shouldn't have any build //*/... commands in here because:

1. They'll build a lot of intermediate targets that may not be necessary for checking if the code works
2. Not all targets are buildable by themselves. Some of them require the context of what they're being built for, i.e. cc_library compilation changes depending on whether it's for JVM or Android. If there is no default set up, likely because is doesn't make sense to build that target by itself, then this would fail.

These scripts should be intent based, "what are you building for" -- testing, publishing, executing.

[adierkens]

I agree with the general sentiment, but I'm not sure I'd go so far to say we shouldn't have any //... commands here. I don't expect them to be used very often, but for things like testing, we may want to test the full project.

Not all targets are buildable by themselves

I'll admit I'm not as familiar with the standard patterns for cc_library -- but if that truly is the case, then I'd expect we should exclude those targets from the build-all target. Maybe it's more beneficial to convert this into a macro for building all of the sub-systems:

build-core
build-plugins
build-android
build-react
build-ios

which I assume is similar to what we'd want to do for lint-all, test-all, etc

[sugarmanz]

I'm not sure I'd go so far to say we shouldn't have any //... commands here. I don't expect them to be used very often, but for things like testing

Using ... expansion for testing is fine, but that's because tests explicitly declare how the dependencies should be built. But I'm sticking to avoiding it for build commands -- you probably don't need to build the targets used for publishing locally, at least at the build-all level. It's somewhat misleading to expect all the tooling targets to also be build with a build-all command.

[sugarmanz]

This also isn't limited to just the cc_library targets - any Bazel target may be transitioned upon to change the underlying toolchain. It's called out in the iOS docs for the Swift-based targets:
https://github.com/player-ui/player/tree/main/ios#bazel

[sugarmanz]

Do we want to have language discrimination for common language things? Practically for performance, maybe, but if I want to lint the project, ideally I'd just lint the whole project.

[KetanReddy]

I don't see any downside to having per language targets in addition to global targets.

[adierkens]

I feel like people are more likely to want to lint smaller subsets of the project based on what they're updating rather than the full project all the time -- but to @KetanReddy's point, we can include other targets as needed.

[KetanReddy]

Should installing just get added to the setup/contributing guides?

[adierkens]

I figured we would first see how well we like using just before fully converting the usage guides over. Then we can update the examples commands and stuff to reference it.