Initial changes for migrating to rules_js
#28957
Open
+15,815
−528
Conversation
This file contains 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
branch
4 times, most recently
from
56b5799
to
426b48a
Compare
devversion
added
action: review
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.
josephperrott
approved these changes
Nov 27, 2024
| @@ -61,6 +61,9 @@ describeBuilder(buildWebpackBrowser, BROWSER_BUILDER_INFO, (harness) => { | |||
| const { result } = await harness.executeOnce(); | |||
|
|
|||
| expect(result?.success).toBe(true); | |||
| console.error(result); | |||
There was a problem hiding this comment.
I think these can be removed.
| @@ -124,6 +126,14 @@ jobs: | |||
| e2e-windows-subset: | |||
| runs-on: windows-latest | |||
| steps: | |||
| # Workaround for: https://github.com/bazel-contrib/bazel-lib/issues/968. | |||
There was a problem hiding this comment.
Is this something we would like to have "permanently" in this config?
There was a problem hiding this comment.
There should be a TODO to remove if you're hinting at this 😄
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
See individual commits.