Rules_nodejs: Local dependencies

[uri-canva]

Is there a pattern for using yarn_install where the package.json has a mix of local and remote dependencies?

For example:

{
  "name": "@canva/foo",
  "version": "0.0.0",
  "private": true,
  "scripts": {
    "eslint": "bin/eslint"
  },
  "devDependencies": {
    "eslint": "^3.12.2",
    "webpack": "^4.5.0",
    "@canva/eslint-config": "../../tools/eslint/eslint-config",
    "@canva/webpack-config": "../../tools/webpack/webpack-config"
  }
}

It seems it can work if I add all the files in both the dependencies and transitive dependencies to data, but that means each package needs to know its transitive dependencies which might change between versions of direct dependencies, and we can't use glob in WORKSPACE so we would have to generate a filelist.bzl file and load it into WORKSPACE or something like that.

filegroup doesn't seem to work because repository rules are evaluated in the analysis phase so they can't access labels that aren't plain files.

Has this come up before? Do most people use node_repositories without yarn_install by loading the node modules from the source tree?

[Chronojam]

+1 for this, keen to see how people are handling this or recommended patterns

[v48]

+1 I have the same issues regarding mixing local and remote node dependencies

[alexeagle]

I'd be interested to try a small repro of this setup, but here's general guidance:

package.json under Bazel is just useful for interop between npm->bazel and bazel->npm dependencies. If you have a dependency within your own repository, it should be a bazel->bazel dependency, which does not require any package.json or *_install rules - just add the other package to your deps

[joeljeske]

Yarn supports local packages using the "file:" protocol. I'm using

yarn add file:./local-packages/my-package

And then it properly is picked up by bazel and yarn as a @npm// dependency

[alisonbelow]

@alexeagle I don't think I understand: making the output of a pkg_npm rule a dependency of a ts_library bazel target results in the following error:

ERROR: /path/to/BUILD:X:1: in ts_library rule //:my_ts_library: 
Traceback (most recent call last):
    File "/path/to/BUILD", line X
        ts_library(name = 'my_ts_library')
    File "/private/var/tmp/_bazel_<user>/<hash>/external/npm_bazel_typescript/internal/build_defs.bzl", line 265, in _ts_library_impl
        compile_ts(ctx, <4 more arguments>)
    File "/private/var/tmp/_bazel_<user>/<hash>/external/npm_bazel_typescript/internal/common/compilation.bzl", line 218, in compile_ts
        d[DeclarationInfo]
<merged target @my_bazel_repo//path/to:my_pkg_npm> doesn't contain declared provider 'DeclarationInfo'

In above example, "my_ts_library" is the ts_library bazel target that is trying to be built, "my_pkg_npm" is the pkg_npm bazel target. The my_ts_library BUILD file looks like:

load("@npm_bazel_typescript//:index.bzl", "ts_library")
ts_library(
    name = "my_ts_library",
    srcs = ["index.ts"],
    deps = [
        "@npm//@types/node",
        "@my_bazel_repo//path/to:my_pkg_npm",
    ],
)

and the import statement in index.ts:

import { } from './my_bazel_repo/path/to/index'

[booninite]

I believe that your dep entry should be pointing at a ts_library or nodejs_binary label, not pkg_npm.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had any activity for 90 days. It will be closed if no further activity occurs in two weeks. Collaborators can add a "cleanup" or "need: discussion" label to keep it open indefinitely. Thanks for your contributions to rules_nodejs!