[19.0.x] Patch port of rules_js migration
#29013
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
angular-robot
bot
added
the
area: build & ci
devversion
force-pushed
the
rules_js_patch
branch
5 times, most recently
from
5eac4e1 to
bf3e8f7
Compare
josephperrott
force-pushed
the
rules_js_patch
branch
3 times, most recently
from
74a6faf to
8d711fd
Compare
josephperrott
force-pushed
the
rules_js_patch
branch
3 times, most recently
from
80f3fb6 to
d229fff
Compare
josephperrott
added
target: patch
clydin
approved these changes
Dec 13, 2024
josephperrott
force-pushed
the
rules_js_patch
branch
from
38d7a29 to
d229fff
Compare
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`: https://github.com/bazel-contrib/bazel-lib/issues/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.
…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.
josephperrott
force-pushed
the
rules_js_patch
branch
from
d229fff to
f94441b
Compare
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Patch port of #28957