Master #1
Open
Master #1
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
Today, the args as specified in the various manifests of the rules_webtesting browsers never make it into the generated karma.conf.js. This results in these arguments never being used when launching Chrome, preventing customization of browsers such as window size, enabling remote debugging, or other flag-based options. This PR fixes this by reading those arguments from the manifest, and adding them to the browsers list in the generated karma.conf.js. Also, this PR includes a change to generated_file_test to allow a golden file to represent a substring of the generated output. Also Also: This PR includes a golden file test that verified that the generated karma.conf.js does read in the specified value. Furthermore, the effect of this can be verified manually via: ``` VERBOSE_LOGS=1 bazel run packages/karma/test/karma:testing_custom_chrome ``` Note the appearance of the additional flags in the new debug output.
Transitive typings are added to typings_depsets, but we were checking the typings array instead. Signed-off-by: Duarte Nunes <duarte@hey.com>
include 10.22.1, 12.18.4, 14.10.0, 14.10.1, 14.11.0 and 14.12.0 in node_versions
It can get ahead of the Chrome version on our CI machine
Architect CLI uses minimist under the hood to parse arguments. Minimist will not convert boolean like values unless they are known options or the `{boolean: true}` option is configured (Which is not in Architect CLI).
When the Karma plugin is used in a testing environment that enforces Trusted Types, its loadFile functionality currently fails due to a Trusted Types violation when assigning to script.textContent. This makes it impossible to use the plugin with integration tests that ensure an application is compatible with Trusted Types. This is fixed by creating a Trusted Types policy specifically for the Karma plugin, and use it to promote any loaded scripts to a TrustedScript before assigning to script.textContent. This is done in a way that is backwards compatible: - The policy is `null` in browsers that don't yet support Trusted Types, in which case the original script string is used as before. - When Trusted Types are supported in the browser but not enforced by the application, the browser treats the TrustedScript as if it were a string when it is assigned to script.textContent.
…need for html escaping
If providing DeclarationInfo we should also give this way for filegroup/bazel CLI to select them
…ncatjs BREAKING CHANGE: users need to change their load statements for ts_devserver Fixes #1082
Procedure: 1 fresh clone git clone git@github.com:bazelbuild/rules_typescript.git rules_typescript_tmp; cd rules_typescript_tmp 2 rewrite history git filter-repo --to-subdirectory-filter third_party/github.com/bazelbuild/rules_typescript --tag-rename '':'rules_typescript/' 3 merge in cd rules_nodejs git remote add rules_typescript_tmp $HOME/Projects/rules_typescript_tmp; git fetch rules_typescript_tmp git merge --allow-unrelated-histories rules_typescript_tmp/master -m "refactor: merge rules_typescript code" 4 add the merge commit SHA to .git-blame-ignore-revs so it doesn't affect browsing history git rev-parse HEAD > .git-blame-ignore-revs; git add .git-blame-ignore-revs
No longer fetch the rules_typescript repo from github, which is inactive and should be archived. Since we switch to local_repository which doesn't have a patches feature, the patches need to be applied to the sources as local modifications now. Fixes #2120
A user reports that their build file generation takes longer than 600 seconds. It's probably a bug that we are so slow, but let's address that separately (maybe in our work for npm v7) Also note we could have made this timeout user-configurable, but I think the extra API surface isn't worth the benefit. Fixes #2231
Co-authored-by: alexeagle <alexeagle@users.noreply.github.com>
Updates the project to the latest version of `@rollup/plugin-commonjs`. For this, `rollup` also needs to be updated as the peer dependency from the CommonJS plugin would not match otherwise. This results in a change in golden files as the rollup output is slightly different. We update the goldens as part of this commit. The update to the latest CommonJS rollup plugin version is in preparation of bundling the runfile helpers into a checked-in file. Since the runfile helpers use a dynamic import for loading the NodeJS patches script, the CommonJS rollup plugin needs to respect those. Currently the CommonJS plugin just invalidates the dynamic require, while the newer version allows us to preserve the dynamic CommonJS import as is.
Introduces a new package called `@bazel/runfiles` that provides runfile helpers for Bazel with NodeJS. The benefit of providing the helpers as a separate package is that people can explicitly specify a dependency on the helpers and also can get typings. The current best practice of using a require w/ an environment variable is untyped and prone to mistakes (and doesn't fit well into the Node/NPM ecosystem).
Adds the ability to link first party deps to subdirectories and adds a new `links` to `yarn_install` and `npm_install` which simplifies linking first party deps into `yarn_install` and `npm_install` managed `node_modules` trees.
The first release of the multi-linker, which landed in 3.2.0, supported linking only 3rd party deps to subdirectories.
------------------------------
This new feature is enabled by new `npm_link` which can add a `LinkablePackageInfo` to any target.
If a target already provides a `LinkablePackageInfo`, it provides a new `LinkablePackageInfo` with a new provided values for `package_path` and `package_name` which informs the linker into which `${package_path}/node_modules/${package_name}` folder to link the package into.
For example, given
```
lib_a/BUILD.bazel:
js_library(
name = "lib_a",
srcs = [
"index.js",
"package.json",
],
package_name = "@somescope/lib-a"
)
```
which makes `//lib_a:lib_a` link to the root node_modules at `node_modules/@somescope/lib-a`
`npm_link` can be used to create a new `lib_a` target that links elsewhere:
```
sub/BUILD.bazel:
npm_link(
name = "lib_a",
target = "//lib_a",
package_path = "sub",
package_name = "@somescope/lib-a",
)
```
which makes `//sub:lib_a` linked to `sub/node_modules/@somescope/lib-a`.
Note: a target may depend on both `//lib_a:lib_a` and `//sub:lib_a` in its `deps` and the linker will link the library to both
`node_modules/@somescope/lib-a` and `sub/node_modules/@somescope/lib-a` respectively.
Alternately, `npm_link` can add a `LinkablePackageInfo` provider to a target that doesn't yet have a `package_name` associated with it,
For example,
```
lib_b/BUILD.bazel:
js_library(
name = "lib_b",
srcs = [
"index.js",
"package.json",
],
)
```
```
sub/BUILD.bazel:
npm_link(
name = "lib_b",
target = "//lib_b",
package_path = "sub",
package_name = "@somescope/lib-b",
)
```
which makes `//sub:lib_b` linked to `sub/node_modules/@somescope/lib-b` while `//lib_b:lib_b` is not linked at all.
The linked target can be of any type, including a simple filegroup. For example,
```
lib_c/BUILD.bazel:
filegroup(
name = "lib_c",
srcs = [
"index.js",
"package.json",
],
)
```
```
sub/BUILD.bazel:
npm_link(
name = "lib_c",
target = "//lib_c",
package_path = "sub",
package_name = "@somescope/lib-c",
)
```
which makes `//sub:lib_c` linked to `sub/node_modules/@somescope/lib-c` while `//lib_c:lib_c` is not linked at all.
------------------------------
With the above abilities, we've also added syntactical sugar to `yarn_install` and `npm_install` which uses `npm_link` under the hood.
For example, given a `sub/package.json` we can define its `yarn_install` as,
```
WORKSPACE:
yarn_install(
name = “@sub_npm_deps”,
package_json = "//sub:package.json",
package_path = "sub",
links = {
"@somescope/lib-a": "//lib_a:lib_a",
"@somescope/lib-b": "//lib_b:lib_b",
}
)
```
which generates two `npm_link` under the hood:
```
@sub_npm_deps//@somescope/lib-a:BUILD.bazel:
npm_link(
name = "lib-a",
target = "//lib_a:lib_a",
package_path = "sub",
package_name = "@somescope/lib-a",
)
```
```
@sub_npm_deps//@somescope/lib-b:BUILD.bazel:
npm_link(
name = "lib-b",
target = "//lib_b:lib_b",
package_path = "sub",
package_name = "@somescope/lib-b",
)
```
which are both linked to `sub/node_modules` (`sub/node_modules/@somescope/lib-a` and `sub/node_modules/@somescope/lib-b` respectively).
This allows the downstream syntactical sugar of depending on first party deps by their package names from the external workspace they are "linked" to.
```
sub/BUILD.bazel:
nodejs_binary(
name = "bin",
entry_point = "bin.js",
data = [
"bin.js"
"@sub_npm_deps//@somescope/lib-a",
"@sub_npm_deps//@somescope/lib-b",
]
)
```
and those deps will be available to the application in `sub/node_modules` where you would expect them to be if they had been defined in the `sub/package.json` itself using yarn workspaces outside of bazel.
`sub/bin.js` can then require those libs with,
```
const liba = require('@somescope/lib-a')
const libb = require('@somescope/lib-b')
```
and those will be resolved to `sub/node_modules/@somescope/lib-a/index.js` and `sub/node_modules/@somescope/lib-b/index.js` with standard node_modules resolution.
* fix(docs): debugging section was moved to different file * chore(docs): add a brief architecture section to DEVELOPING.md * chore(docs): document host platform toolchain workaround * chore(docs): add link to changing-rules.md in DEVELOPING.md * chore(docs): add link to from_source example
Based on Bazel's documentation, values provided through the workspace_status_command can contain whitespace on the same line the key is defined on: > The key names can be anything but they may only use upper case letters and underscores. The > first space after the key name separates it from the value. The value is the rest of the line > (including additional whitespaces). The `parseStatusFile` utility function is updated to rely on a regex for performing this parsing to match the described behavior.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 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.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?
Other information