build: ensure all entry-points are included in release package

[devversion]

(1) Overhauls the whole release packaging structure in Bazel. Since it is
very verbose to put everything into a single .bzl file in the project root,
information for each release package will be stored in the actual package
folder in a file called config.bzl.

(2) We no longer use the term PACKAGE for entry-points of
packages. It's not correct and easy to confuse with the actual package.

(3) We group entry-points in nested arrays. This has no effect for now, but
it gives us a nicer way of configurating (nested) entry-points. It might become
useful in the future as well as we have information about nested entry-points of
an entry-point.

(4) Revisits the list of all entry-points so that we now include all */testing
entry-points in the release output. Also a few MDC prototypes were not included
in the Bazel material-experimental release output. Same as clipboard in cdk-experimental.

(5) Simplifies the logic to generate the rollup globals (through functions). Also we move the
rollup globals into a separate .bzl file. Also rollup globals are now automatically passed
into the ng_package rule.. so we don't need to re-declare them for each package.

In follow-ups/future: we should work on validating somehow that all entry-points are listed in these files. To avoid that we accidentally forget some.

[devversion]

I'm not sure about the naming here. We basically have two types of entry-points:

• Public non-test entry-points.
• Test entry-points.

Since we are lazy here and not want to manually list specific entry-points used by the a11y-app, I figured I'd add a NO_TEST_TARGETS variable as well. We don't want to build the testing entry-points unnecessarily.

Also we need some kind of variable for non-testing entry-points as only those have an overview (as of right now) and a scss_lib.

[josephperrott]

An option would be, instead of creating two exports, export an object that has ALL_TARGETS and WITHOUT_TEST_TARGETS
e.g. MATERIAL.ALL_TARGETS and MATERIAL.WITHOUT_TEST_TARGETS

[devversion]

Sounds like an option, but I'm not sure if we benefit from it. Especially since it would be not consistent with the SCSSexport variable for example.

Regardless of whether we use one or two exports, I guess we'll always use something like NO_TESTS or WITHOUT_TESTS. And this is the part where I look for an alternative 😞 (it feels somehow dirty but it's actually the most clear name; and will avoid confusion)

[jelbourn]

I'd prefer something like material_component_entrypoints and material_testing_entrypoints, and anywhere you wanted both you explicitly concat them, which I think would prevent anyone from accidentally including something they didn't mean to.

(side note: I looked up the bzl style guide for this change, and they do recommend lower_snake_case, which we could do at a later date)

[devversion]

I like the idea of just having non-testing and testing. Concatenating both should be straightforward enough 👍

Slightly unsure about component though. Not all entry-points expose a component. If we can improve that somehow, then I think we have a good naming convention. Can't think of anything else than no_test.

[jelbourn]

component isn't perfect, but I think it's preferable to something like without_tests. I also considered words like primary, main, root, top lib, browser, but I didn't think of any of these work as well.

[josephperrott]

Overall I like the direction of it

[josephperrott]

An option would be, instead of creating two exports, export an object that has ALL_TARGETS and WITHOUT_TEST_TARGETS
e.g. MATERIAL.ALL_TARGETS and MATERIAL.WITHOUT_TEST_TARGETS

[jelbourn]

I'd prefer something like material_component_entrypoints and material_testing_entrypoints, and anywhere you wanted both you explicitly concat them, which I think would prevent anyone from accidentally including something they didn't mean to.

(side note: I looked up the bzl style guide for this change, and they do recommend lower_snake_case, which we could do at a later date)

[jelbourn]

LGTM

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}