rules_node icon indicating copy to clipboard operation
rules_node copied to clipboard

npm_library should be a repository_rule

Open mattmoor opened this issue 8 years ago • 3 comments

npm_library should fetch dependencies during WORKSPACE instantiation.

These "repository rules" can have variable outputs, which avoid the need to declare all of the constituent elements as you have here: https://github.com/dropbox/rules_node/blob/master/examples/npm/ts-loader/BUILD#L7-L23.

mattmoor avatar Nov 28 '17 22:11 mattmoor

It would also (ideally) consume package-lock.json. I would be happy to hop on a quick hangouts call if you want to know how I was able to do this for rules_python and keep requirements.txt as the source of truth.

My email is my GitHub handle @ google.com

mattmoor avatar Nov 28 '17 22:11 mattmoor

I think you're right that making npm_library a repository rule is the right direction to go in. I'll send you an email so we can discuss moving in that direction.

(At Dropbox, we have some pretty nice internal tooling for generating BUILD files so it's normal internally to generate all the files a rule is going to create, but that doesn't fit well with how the open source world is using Bazel.)

samertm avatar Nov 30 '17 06:11 samertm

Yeah, I found your tool after I filed this. I think that essentially what you want is for the repository rule to run this tool (or something like it) automatically.

FWIW, if you do this in a repository rule named npm then the references in things like this could be @npm//express.

A key distinction between what you should do in WORKSPACE vs. BUILD is network access. e.g. WORKSPACE is designed to fetch everything remote prior to the BUILD, so within a network sandbox (as in some distributed builds) these rules won't work properly because they have to fetch stuff over the network at BUILD time.

I'm happy to provide some pointers here, as I've done battle with WORKSPACE/BUILD a few times before :)

mattmoor avatar Nov 30 '17 15:11 mattmoor