--incompatible_disable_managed_directories: deprecate managed_directories()

[lberki]

The reasons for deprecation and the migration steps are documented in the design doc:

https://docs.google.com/document/d/1u9V5RUc7i6Urh8gGfnSurxpWA7JMRtwCi1Pr5BHeE44/edit

This represents a loss of functionality for Bazel. We believe this is possible because the motivating use case for managed_directories() was rules_nodejs, which now recommends against using it.

The incompatible flag will remain available for a month.

[SrodriguezO]

We use managed_directories at Lucid to avoid needing to install node_modules manually for tooling to work. We clean expunge between CI builds anyway, so we don't experience the mentioned downside from the node_nodules directory also being deleted between builds.

The contents of our managed directory change often, and requiring devs to run some command in order to bring their workspace up-to-date would become tiresome. It'd be extra painful for developers using worktrees. It's convenient for it to happen automatically whenever Bazel loads.

We don't absolutely need this feature, just chiming in that we currently do rely on it.

[alexeagle]

for tooling to work

Could you give some motivating examples there? What tooling do you run outside of Bazel, where you'd want versions of those tools to update following a bazel command? I can think of typescript as an obvious case, where an editor will use the version of TypeScript found in the node_modules folder and you'd want developers getting intellisense for the same TS version as Bazel will run to type-check their code. Do you have others?

[SrodriguezO]

When the typescript language server is running, it must be able to find dependencies in order to provide type information and go-to support.

Additionally, we use some IDE extensions that rely on the presence of node_modules, such as ESLint and Prettier. Although our definitive "formatter" that runs in CI is powered by Bazel, the IDE extensions improve our developers' dev experience as they get mostly-correct formatting and linting on the files they're working with.

It's nice to get this "for free" when Bazel loads rather than needing manual intervention (especially for developers using git worktrees)

[lberki]

@SrodriguezO : given the "don't absolutely need this feature" part, I won't consider this a blocking issue.

Maybe you can get away with putting node_modules into .bazelignore and rigging some script up to symlink that to wherever rules_nodejs puts its node_modules directory?

[alexeagle]

@SrodriguezO I see how that's a handy workflow. But it only happens to work when the user's workflow is

• change git worktrees
• run a bazel build of a target that depends on the npm install
• try to run a tool outside of Bazel

Obviously if you just changed worktrees and then ran the tool, nothing would have updated the node_modules directory. But I understand you have this working okay for you.

There's yet another line of reasoning for this change:

Having a single node_modules folder for the entire project in the external folder is not the only way to integrate npm with Bazel. In aspect-build/rules_js for example we use pnpm as the package manager (rather than npm or yarn) which uses a "content addressable store" for the downloaded packages in external. Then the node_modules tree is constructed in bazel-bin per-action, containing only packages needed for it.

As such, I think Bazel core shouldn't have to carry a feature which is particular to just one NodeJS implementation choice, and not inherent to that problem.