Add support for Label in nodejs_binary and rollup_bundle entry_point

[gregmagolan]

Replaces #480

Closes #32

⚠️ Depends on upstream sass change: bazelbuild/rules_sass#87
⚠️ Depends on upstream rules_typescript change: bazelbuild/rules_typescript#453
⚠️ Depends on downstream angular-bazel-example change: angular/angular-bazel-example#450

PR Checklist

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature (please, look at the "Scope of the project" section in the README.md file)
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• Other... Please describe:

What is the current behavior?

nodejs_binary#entry_point was a string.

What is the new behavior?

nodejs_binary#entry_point is now a Label.

Does this PR introduce a breaking change?

• Yes
• No

The entry_point accepts a target's name as an entry point. If the target is a rule, it should produce the JavaScript entry file that will be passed to the nodejs_binary rule). For example:

       filegroup(
           name = "entry_file",
           srcs = ["workspace/path/to/entry/file"]
       )
       nodejs_binary(
         name = "my_binary",
         ...
         entry_point = ":entry_file",
       )

If the entry JavaScript file belongs to the same package (as the BUILD file), you can simply reference it by its relative name to the package directory:

        nodejs_binary(
          name = "my_binary",
          ...
          entry_point = ":file.js",
        )

[googlebot]

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this state. It's up to you to confirm consent of all the commit author(s), set the cla label to yes (if enabled on your project), and then merge this pull request when appropriate.

ℹ️ Googlers: Go here for more info.

[alexeagle]

interesting that you don't have to specify foo.js in the srcs. It seems like it reduces one way users can fall off the happy path. on the other hand it means you have to consider entry_point when enumerating the inputs to a rule.
Should we give it more thought?

[gregmagolan]

Hmmm. That's a good question. One strike against doing it this way is that if the user specifies :foo.ts as the entry_point they still have to add the ts_library :foo_lib to deps. I'm not sure what is best. On the other hand, the user adding :foo.js to entry_point and to srcs doesn't break anything with the current approach.

[gregmagolan]

There is some smell however with not having the file in srcs as seen here: https://github.com/bazelbuild/rules_nodejs/pull/777/files#diff-6e8a939ed5da5eca956cd2f53701b77e. Probably better to force it to be specified

[googlebot]

A Googler has manually verified that the CLAs look good.

(Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.)

ℹ️ Googlers: Go here for more info.