…44238)

Wires up the integration test rule from the shared dev-infra package,
while also deleting the old integration test rule.

The readme is updated to reflect the changes that are being made
to run with the new integration rule. Overall one major difference is
that we will declare the integration test targets within each test
directory, making those actual bazel packages. This is more idiomatic
within Bazel and also reduces the computation within Skyframe as less
globs need to be evaluated for example.

PR Close #44238

…egration test structure (#44238)

As mentioned in the previous commit, integration tests will be declared
in subpackages of `//integration`. For these tests to still rely on the
NPM packages from `HEAD`, we need to update the visibility.

PR Close #44238

Sets up the test targets for integration tests with the new rule.
The targets will match the configuration of the previous integration
test setup (through the dictionary in a `bzl` file).

Note: We already add `setup_chromium` based on whether Chromium tests
run as part of this integration test. In a follow-up commit we can then
remove puppeteer and rely on the Bazel-managed version of Chromium.

PR Close #44238

)

Sets up the Bazel integration test with the new integration rule. This
commit is separate from the other changes because it required some
additional work. i.e.

The test has moved from `integration/bazel` to `integration/<..>/bazel`
where `<..>` is a new Bazel package defining the integration test.

This is necessary because we could not declare the integration test
within the `BUILD.bazel` file actually being part of the nested bazel
workspace. In those cases we can just define it at a higher-level and
use integration test `working_dir` attribute.

PR Close #44238

…zel-managed chromium (#44238)

Switches the integration tests form Puppeteer/webdriver-manager to the
Bazel-managed Chromium/Chromedriver. This is now possible with the new
integration test rule for which we can consult the
`dev-infra/bazel/browsers` toolchain and setup environment variables.
This has been configured already in a previous commit.

This commit also includes some additional small cleanups necessary for
the new integration test rule:

* The `test.sh` scripts have been renamed as they would conflict with
  the `test.sh` scripts generated by the integration test rule.
  Previously this was not an issue because tests were declared at a
  higher-level. As mentioned though this has other downsides and it is
  trivial to rename the file.

* Related to the point above, since tests are now declared witin the
  actual test folder (for perf e.g.), `package.json` files setting
  `"type": "module"` will accidentally cause the `nodejs_test`-generated
  files to be considered ESM. This is not correct and likely needs to be
  fixed upstream in `rules_nodejs` where explicit `.cjs` extensions
  should be used. This is only happening **once** in the `injectable-def`
  test so it is acceptable doing that for now.

PR Close #44238

…ipped rule (angular#44238)

The import ESM/CJS interop lint rule has been ported to the shared
dev-infra package, so we can remove the local version here.

PR Close angular#44238

…ngular#44238)

Wires up the integration test rule from the shared dev-infra package,
while also deleting the old integration test rule.

The readme is updated to reflect the changes that are being made
to run with the new integration rule. Overall one major difference is
that we will declare the integration test targets within each test
directory, making those actual bazel packages. This is more idiomatic
within Bazel and also reduces the computation within Skyframe as less
globs need to be evaluated for example.

PR Close angular#44238

…egration test structure (angular#44238)

As mentioned in the previous commit, integration tests will be declared
in subpackages of `//integration`. For these tests to still rely on the
NPM packages from `HEAD`, we need to update the visibility.

PR Close angular#44238

…r#44238)

Sets up the test targets for integration tests with the new rule.
The targets will match the configuration of the previous integration
test setup (through the dictionary in a `bzl` file).

Note: We already add `setup_chromium` based on whether Chromium tests
run as part of this integration test. In a follow-up commit we can then
remove puppeteer and rely on the Bazel-managed version of Chromium.

PR Close angular#44238

…ular#44238)

Sets up the Bazel integration test with the new integration rule. This
commit is separate from the other changes because it required some
additional work. i.e.

The test has moved from `integration/bazel` to `integration/<..>/bazel`
where `<..>` is a new Bazel package defining the integration test.

This is necessary because we could not declare the integration test
within the `BUILD.bazel` file actually being part of the nested bazel
workspace. In those cases we can just define it at a higher-level and
use integration test `working_dir` attribute.

PR Close angular#44238

…zel-managed chromium (angular#44238)

Switches the integration tests form Puppeteer/webdriver-manager to the
Bazel-managed Chromium/Chromedriver. This is now possible with the new
integration test rule for which we can consult the
`dev-infra/bazel/browsers` toolchain and setup environment variables.
This has been configured already in a previous commit.

This commit also includes some additional small cleanups necessary for
the new integration test rule:

* The `test.sh` scripts have been renamed as they would conflict with
  the `test.sh` scripts generated by the integration test rule.
  Previously this was not an issue because tests were declared at a
  higher-level. As mentioned though this has other downsides and it is
  trivial to rename the file.

* Related to the point above, since tests are now declared witin the
  actual test folder (for perf e.g.), `package.json` files setting
  `"type": "module"` will accidentally cause the `nodejs_test`-generated
  files to be considered ESM. This is not correct and likely needs to be
  fixed upstream in `rules_nodejs` where explicit `.cjs` extensions
  should be used. This is only happening **once** in the `injectable-def`
  test so it is acceptable doing that for now.

PR Close angular#44238