Closed dgp1130 closed 1 year ago
I tried playing around with nested_packages
a bit but found it less than ergonomic. Much like how pkg_npm()
normally works, you can't nest a package from a sibling directory, so having //packages/rules_prerender:pkg
nest //packages/internal_dep:pkg
has no effect. Instead, I still need the pkg_npm()
target to live in the repository root, so having //:pkg
nest //packages/internal_dep:pkg
does work.
However, this nesting does less than I was hoping. I expected it to make the internal dependency available at the same package name, but it doesn't seem to do anything in that regard so you get errors like:
Cannot find module '@rules_prerender/annotations'. Please verify that the package.json has a valid "main" entry
The best solution I found was to add a substitution on the package to rewrite the internal package specifier (@rules_prerender/annotations
in this case) with an "absolute" import internal to the package its called from (rules_prerender/packages/annotations
). Since it's being imported from rules_prerender
, the rules_prerender/...
specifier always resolves to an "absolute" path under the package, and works when imported from any subdirectory in the package.
Unfortunately @aspect_rules_js
's version (npm_package()
) does not support nested packages or substitutions, so I think this approach won't be able to evolve with the new toolchain. I'll have to ask around to see if there are any suggestions as to the "right" way of doing this.
Current progress is in ref/nested-packages
.
Duplicate of #67
From #49, where we removed
link_workspace_root = True
:Currently everything is relative imported, but all across the repository which doesn't scale well and doesn't vendor into NPM packages.