Example showing how to use rules_js in multiproject monorepo about bazel-examples HOT 9 CLOSED

Just contributed funding for this issue on https://opencollective.com/aspect-build/projects/rules_js (payment from Twisp)

from bazel-examples.

This one is already being tracked:

• aspect-build/rules_jest#17

Linting is busted right now because of the way eslint tries to extend from the next.js config. @gregmagolan will file an issue about that separately, it's probably a separate project.

The devserver in next.js currently restarts on each Bazel rebuild, it needs to be taught the ibazel_notify_changes protocol from https://github.com/bazelbuild/bazel-watcher#running-a-target. It looks to me like https://nextjs.org/docs/advanced-features/custom-server might give us the affordance to run their devserver but control when they refresh content from the disk. It will take a bit of experimentation to confirm.

from bazel-examples.

@tannerwelsh I made some progress on this this week. It doesn't look feasible (at least not without big patches to Next.js and webpack) to adapt the next.js devserver to play nicely with how Bazel lays out the runfiles of a binary so I abandoned that approach and now have a general purpose devserver/watchmode rule going in rules_js that instead adapts Bazel to what the Next.js devserver expects to find on disk. aspect-build/rules_js#540.

Should have something merged here sometime next week.

from bazel-examples.

Landed the change to generalize the next targets into a portable next() macro and add a working ibazel next dev devserver. 772bf64

Will still add an example up code sharing here in the next day or two.

from bazel-examples.

@tannerwelsh This PR should address the remaining items in your list: #128

LMK how it works out on your end and if you need anything else shown in here.

from bazel-examples.

This one is already being tracked:

• jest_test should also create a run target to update snapshots rules_jest#17

Thanks! Updated the description to strike that from the specs.

Re: linting, thanks for the explanation re: why this would be more complicated. To start, these shouldn't be necessary for development so long as there's an option to run these commands outside of the Bazel context, i.e. with scripts in a package.json like already exists in the next.js example:

  "scripts": {
    "dev": "ibazel run //:dev",
    "build": "bazel build //:build",
    "start": "ibazel run //:start",
    "lint": "next lint"
  },

from bazel-examples.

That's great, thanks @gregmagolan! Looking forward to seeing it in action

from bazel-examples.

PR landed.

The devserver is working nicely now using the new js_run_devserver rule. Linting still doesn't run under Bazel but that is something I'd like to get to eventually.

from bazel-examples.

Dang this is looking great, thanks @gregmagolan ! I just did some preliminary poking around, and everything looks like it should translate nicely to our system. Once I get deeper into the weeds of translating this example into a real-world context, I'll follow up with any feedback/snags I bump into.

Thanks also to @alexeagle for coordinating! Really happy with the way this worked out.

from bazel-examples.