Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial changes for migrating to rules_js #28957

Merged
merged 16 commits into from
Dec 16, 2024
Merged

Conversation

devversion
Copy link
Member

@devversion devversion commented Nov 25, 2024

See individual commits.

@angular-robot angular-robot bot added the area: build & ci Related the build and CI infrastructure of the project label Nov 25, 2024
@devversion devversion force-pushed the rules_js branch 4 times, most recently from 56b5799 to 426b48a Compare November 26, 2024 18:02
@devversion devversion added action: review The PR is still awaiting reviews from at least one requested reviewer target: patch This PR is targeted for the next patch release labels Nov 26, 2024
@devversion devversion marked this pull request as ready for review November 26, 2024 20:33
@devversion devversion force-pushed the rules_js branch 3 times, most recently from 0aecb1f to 7704054 Compare November 27, 2024 15:04
Copy link
Member

@josephperrott josephperrott left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

yarn.lock Show resolved Hide resolved
@alan-agius4 alan-agius4 added merge: squash commits When the PR is merged, a squash and merge should be performed merge: fix commit message When the PR is merged, rewrites/fixups of the commit messages are needed labels Nov 28, 2024
@alan-agius4
Copy link
Collaborator

The following commit 7704054 has an incorrect commit message.

@alan-agius4 alan-agius4 added action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews and removed action: review The PR is still awaiting reviews from at least one requested reviewer labels Nov 28, 2024
@devversion devversion removed action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews merge: squash commits When the PR is merged, a squash and merge should be performed merge: fix commit message When the PR is merged, rewrites/fixups of the commit messages are needed labels Nov 29, 2024
@devversion devversion force-pushed the rules_js branch 3 times, most recently from e072b8d to d8e3479 Compare December 2, 2024 13:41
@josephperrott josephperrott force-pushed the rules_js branch 3 times, most recently from 9c0b2bb to da66d2b Compare December 12, 2024 13:54
@josephperrott josephperrott added action: merge The PR is ready for merge by the caretaker and removed state: WIP labels Dec 12, 2024
@josephperrott josephperrott requested a review from clydin December 12, 2024 14:27
WORKSPACE Outdated Show resolved Hide resolved
@josephperrott josephperrott force-pushed the rules_js branch 2 times, most recently from 3ad20a6 to 29b3372 Compare December 13, 2024 18:06
This is necessary for an incremental migration to `rules_js` which
requires Bazel v6. Bazel v6 removed the managed directories feature,
which means we no longer can rely on symlinked node modules as the Bazel
repository; but rather need to duplicate dependencies. This is
okay/acceptable to enable the incremental migration.
This also requires us to move patches from `patch:` protocol to
`patch-package` temporarily. This is because we need to temporarily use
pnpm and yarn berry in hybrid, and both don't have any overlap in how
patching works; and pnpm would fail if it sees the `patch` protocol.
This commit sets up `rules_ts`, providing the `ts_library` equivalent
for the `rules_js` migration.
This commit introduces a new interop Starlark macro/rule for using
`ts_project` throughout the repository without having to migrate
any dependant or dependencies; allowing for incremental migration
to `ts_project`.
This is necessary as the current rule is not clever enough to detect
when a given file is already "generated" and inside `bin`.

This is important because `package.json` files are always copied to bin
for `npm_package`, but the `package.json` may already be copied from
e.g. `ts_project#data`. This shouldn't cause a Bazel action conflict.
This commit updates the architect devkit package code to use
`ts_project`. We specificially don't migrate the jasmine node test yet
as we want to experiment further with the incremental migration.
It seems that the chunk deterministic name has changed after
recent node module /lock file changes. It's unclear what specifically is
involved in Webpack's chunk name generation, but the output and all
other tests still look good; which makes this is a rather safe update to
the new chunk name. Consulting with CLI team members explained that this
can happen quite often.
… setup

- it seems to be disabled by default for actual production .ts files;
  but the rule is in "error" mode for spec files.
- The rule doesn't seem to properly support mono-repos when configured properly.
i.e. it only considers the top-level package.json — hence doesn't deal with cross-workspace deps.
Workaround until `rules_js` imports the latest version of
`aspect_bazel_lib`: bazel-contrib/bazel-lib#968
In our dev-infra sync we decided that we want to have less
ambiguous naming for node modules from the workspace root vs. node
modules that are local to the package.

Consider the confusion between: `//:node_modules` and `:node_modules`.
This commit fixes this by naming the workspace `node_modules` as
`:root_modules`. This does not have an effect on runtime of NodeJS
output because `rules_js` continues to lay out the root modules as
`/node_modules` folder; as it should.
I suspect there were some versioning changes with the e.g. `hoist =
false` setting in npmrc; so eslint now starts failing about this
unnessary type cast. Seems reasonable so this is committed without
deep investigation.
…nt error

I suspect there were some versioning changes with the e.g. `hoist =
false` setting in npmrc; so eslint now starts failing about an import
from `webpack-server.ts` resulting in unnecessary type cast lint errors.

The existing mapping didn't work due to the underscore conversion, so
this makes sense, and fixing the path mappings works.
devversion and others added 3 commits December 16, 2024 17:01
…dbox issues

For the `rules_js` migration we are introducing a new ruleset for
Angular rules. These rules are not used here by the CLI as we don't use
`ng_module`, but we are building the rules in a way where we expose a
worker binary that can also work with vanilla TS.

The worker significantly speeds up compilations, bringing them to
equivalent speeds of `ts_library`, and **importantly** fixes/avoids
issues when actions are executing outside sandbox. E.g. on Windows where
the tsc compilation currently can see many other files that aren't
action inputs; and accidentally picks them up.
@clydin clydin merged commit b1500d3 into angular:main Dec 16, 2024
29 of 30 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
action: merge The PR is ready for merge by the caretaker area: build & ci Related the build and CI infrastructure of the project target: minor This PR is targeted for the next minor release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants