rules_nodejs
rules_nodejs copied to clipboard
feat(examples) demonstrate building nextjs app
PR Checklist
Please check if your PR fulfills the following requirements:
- [ ] Tests for the changes have been added (for bug fixes / features)
- [ ] Docs have been added / updated (for bug fixes / features)
PR Type
What kind of change does this PR introduce?
- [ ] Bugfix
- [x] Feature (example)
- [ ] Code style update (formatting, local variables)
- [ ] Refactoring (no functional changes, no api changes)
- [ ] Build related changes
- [ ] CI related changes
- [ ] Documentation content changes
- [ ] Other... Please describe:
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Example demonstration how to build a nextjs application
Does this PR introduce a breaking change?
- [ ] Yes
- [x] No
Other information
Cool, do you want feedback on this PR and make edits yourself, to learn more Bazel stuff? Or would you like me to just fix it up?
Cool, do you want feedback on this PR and make edits yourself, to learn more Bazel stuff? Or would you like me to just fix it up?
Will love to lean more stuff :grin:
@alexeagle just a friendly reminder on the review.
I'm currious, why are all the files wrapped as ts_project
?
I'm currious, why are all the files wrapped as
ts_project
?
ts_project is the recommended way of building typescript code
I'm currious, why are all the files wrapped as
ts_project
?ts_project is the recommended way of building typescript code
I understand that, but why not a big ts_project with all the file in-it ? It's easlily maintainable IMO
I'm currious, why are all the files wrapped as
ts_project
?ts_project is the recommended way of building typescript code
I understand that, but why not a big ts_project with all the file in-it ? It's easlily maintainable IMO
At scale a big ts_project doesn't work because you lose the ability to utilise caching and even to parallise your builds with RBE, since a single file change means you have to rebuild everything in CI. Also fine-grained dependencies is bazel's best practice
Also at my company we have gazelle tool for generating BUILD files, so there is no maintenance cost.
Also (out of curiousity), why use bazel if you will just have one big ts_project.
I have some potential clients looking into next.js with Bazel, so it would be nice to get this in.
Re. the discussion of granularity of ts_project
targets: there is a tradeoff. If you have a BUILD file generator like Gazelle, then there's not much expense for developers to tell Bazel the dependency graph, and you can afford to have a lot of those files. However there isn't a canonical Gazelle TS extension yet (Aspect is working on one: https://github.com/aspect-build/rules_js/pull/21).
As you say, a single ts_project
for the entire application plus libraries doesn't deliver on Bazel's promise of faster builds through incrementality.
So a smaller number of "libraries", each with a ts_project
rule, is a pretty good compromise.
We opened source our Gazelle plugin that works well for both TS and JS. We have two options, fine grain ( per file target) or aggregated ( per package targes). But we have never tried per package at scale.
Hey @ewianda - have any interest in picking this up again with me? I'm working over here on it 👉🏻 https://github.com/aspect-build/bazel-examples/tree/next/next.js
with the goal of not just calling the next
tool to wrap their build system, but fully replace their build system with Bazel.
Hey @ewianda - have any interest in picking this up again with me? I'm working over here on it 👉🏻 https://github.com/aspect-build/bazel-examples/tree/next/next.js with the goal of not just calling the
next
tool to wrap their build system, but fully replace their build system with Bazel.
Yes i am interested
We have a Bazel + next.js example here now https://github.com/aspect-build/bazel-examples/tree/main/next.js
@ewianda sorry we didn't get this one merged, but I'd still love to have more of your contributions in the future! That example probably needs more polish and features.