build_bazel_rules_nodejs should rarely require updates

[alexeagle]

The starlark-only package is harder to update because the version is in the WORKSPACE and not in package.json

This means that every time we cut a rules_nodejs release, we have to update WORKSPACE in the @angular/bazel builder package for users to pick up the change.

We want the build_bazel_rules_nodejs starlark package to be "evergreen" and it should rarely require bugfixes, which means it should have minimal bootstrapping code.

[Globegitter]

Isn't that the aim of the experimental resolved WORKSPACE file: https://blog.bazel.build/2018/09/28/first-class-resolved-file.html?

And hopefully I'll also be soon able to finish up bazelbuild/bazel#7424 which would imo be the second piece of the puzzle to get persistent caching of that 'evergreen' git repository.

[alexeagle]

Even with WORKSPACE.resolved, you end up with the user needing to manage their updates in Bazel-specific files.

I think we should be at a place in the future where the long-term stability means your Bazel version and your WORKSPACE file stay fixed, in the same way you rarely update nodejs versions.

All the code changes we want to ship ought to be pushed on npm, so that for a frontend developer, introduction of Bazel doesn't change their fundamental workflow that all deps are managed in package.json and npm outdated tells you what updates you can grab.

In practice, it means moving rollup to @bazel/rollup and also doing something with history-server and http-server packages.

[alexeagle]

couple more releases and we can remove rollup_bundle from builtin, then we should do a final pass to see if there's anything else we can drop