# Linking first-party libraries

The "linker" is the part of rules_nodejs that makes node runtime find your first-party depedencies within your monorepo. It's rougly like the "npm link" command.

Today, you can use `ts_library` to produce a linkable package, but if you don't author in typescript, you have to use an undocumented `js_library` rule.

Also the current approach uses a hard-coded attribute name `module_name`/`module_root` which is annoying if you want to expose a provider from an existing rule without introducing such attributes.

## Proposal

Re-use the `pkg_npm` rule. Today the meaning of this rule is "make some JS code publishable to npm to be used outside the monorepo". We expand the meaning of the rule to also be "expose this JS code to be linked elsewhere in the monorepo."

1. `pkg_npm` exposes a new provider. Call it `LinkableInfo`. (`NpmPackageInfo` seems like the right name, but it's an annoying change to roll out since current usages assume it always represents a third-party node module)
2. The linker has an aspect that already walks the deps looking for linkable packages - it should look for the `LinkableInfo` and contribute a mapping from the package directory to the package.json file (actually no value is needed because the package.json always has that name and is in the package output dir)
3. The linker already gets a manifest of first-party dependencies. It should check if the value is a path to a package.json and if so, read the package.json to get the name. Then it can link from the name to the package output dir.
4. `pkg_npm` should be legal as a .d.ts or .js dependency. So it should expose `JsModuleInfo` and `DeclarationInfo`, but these will just point to the output tree, where tools that read the providers should understand npm packages. For example, TS will look in the directory for a `package.json#typings` value or use `index.d.ts`.

By using pkg_npm, you opt-in to using a tree artifact output, which reduces incrementality. Any time any file in the package changes, all downstream actions are cache misses and need to re-run. If you want to have the optimal incrementality, you should not use pkg_npm. Instead use TS composite projects or some other tooling-specific mechanism to break up the work without needing the concept of package.json files or npm packages in the boundaries.