Get desktop application:
View/edit binary Protocol Buffers messages
Static asset mapping for development web server which is served when a matching webpath can't be found in transitive srcs.
Used in:
Absolute path on web server. Should be unique across repeated entries.
Path on file system. This path can be absolute or relative to TEST_SRCDIR. If this path is a directory, then webpath will be stripped off the request path and the remaining portion will be resolved against this path.
Information produced by JsChecker about a single JS library rule. This data structure allows JsChecker to propagate information up the build graph to other JsChecker and JsCompiler invocations. Some of this information is extracted from the abstract syntax tree of sources.
Canonical build target for this rule, e.g. @com_google_javascript_closure_library//closure/goog
Indicates if this proto was outputted by a legacy rule, e.g. js_library. This helps JsCompiler know which source files in the transitive closure should be treated with greater leniency.
JavaScript namespaces provided by this rule. This field is used to determine what things srcs in parent closure_js_library rules are allowed to include or require. A namespace can either be a Google namespace, e.g. goog:goog.dom, or it can be an ES6 module namespace, e.g. some/es6/module/path. ES6 module names are created by stripping off the longest root prefix and extension suffix from the Bazel path. How roots are determined is documented by the find_js_module_roots() function. If a source file contains a goog.provide() or goog.module() statement, then it's not included in this list as an ES6 module name.
DiagnosticType keys that JsChecker wants to propagate up to JsCompiler. This will not include codes that JsChecker was solely responsible for checking, e.g. linting. This also does not necessarily map to the values in the suppress attribute of closure_js_library, which is permitted to have DiagnosticGroup names. Those values are expanded into their DiagnosticType keys before being written to this field.
Canonical ES6 module name of all srcs. This field is used by JsCompiler so it can map Bazel source paths back to the ClosureJsLibrary proto that originated it, even across Bazel repositories. This field is almost identical to the namespace field, except it includes ES6 module names for files that declare Google namespaces. Even though these names can be short and arbitrary---depending on how repositories are configured and whether or not the includes attribute is being used---they can still be used as a key lookup for this proto because closure_js_library guarantees they're unique within any transitive closure.
Protobuf representation of Multimap<String, String>.
Used in:
Key, which is considered unique across the MultimapInfo.
Value, which might be required to be unique for a given key. This must not be empty.
Input parameters for the WebCompiler, WebLinker, and WebDeployer programs. This is stored to disk by Skylark code. It is always serialized as text with the .pbtxt extension. This proto is only good for a single ctx.action run. It is only stored to disk because Blaze currently leaves us no other option.
Canonical build target for this rule, e.g. @com_google_javascript_closure_library//closure/goog
Path of output.pb file to which WebfileManifestInfo is written. This field also implies a concomitant output.blob file. This field must be present.
List of srcs declared by target, in no particular order. This field may be empty. If entries are specified, the src.path field must be set.
Blaze execroot paths of all transitive binary proto WebfilesInfo manifests in reverse topological order. This includes all transitive deps, runtime_deps, as well as the exports of direct dependencies, which includes the exports those exports exported. This field may be empty.
List of which dep paths are direct deps, including their exports, in no particular order. This must be a subset of dep and must not overlap with runtime_dep.
List of which dep paths are runtime deps, including their exports, in no particular order. This must be a subset of dep and must not overlap with direct_dep.
Suppress codes used to turn errors into warnings.
Web file index entry. Within a single manifest, the WebfileInfo message can be used to map a web path to zero or more files on disk, as well as zero or more entries in the blob.
Used in:
,Absolute path of file on web server. This field must be unique within a particular WebfileManifestInfo message, because zip files are not allowed to contain duplicate filenames.
Blaze execroot path. This field is only present when it's passed using a WebRuleInfo message. After the WebCompiler run, this field is cleared, since Blaze paths are usually only valid for a single ctx.action invocation and the canonical source of data becomes either the runpath or the incremental zip.
Runfiles path of original source file relative to TEST_SRCDIR. This is used by WebfilesServer to read the file with live source reloading that goes faster than iblaze can regenerate the proto. This field will be absent for files generated by the compiler and linker.
Indicates the canonical source of data for this file is in the associated incremental zip archive. If this field is false, then offset, length, and token should be absent. This field is not set when passed via WebRuleInfo, but always becomes set once run through WebCompiler, et al.
Byte offset of data in associated .i.zip file. This field must be present if in_zip is true. This field allows us to seek to a specific byte offset in the zip file to obtain an individual file, without having to scan through the whole archive.
Opaque binary token which can be used for caching this web file. This token is guaranteed to be large enough to qualify for global uniqueness and therefore can be used as a key in and of itself. If this token is empty, no caching should be performed.
Manifest generated by a web build rule target. This file is stored to disk as a binary protobuf with the .pb extension. It will always be accompanied by a .i.zip with the same name. The incremental zip file contains all the sources of a rule and any other compiler output, while excluding transitive data. Together these files serve as an archive format that serves the same purpose as jar, but more efficiently. This manifest maps web paths defined or produced by a single build rule to byte offsets in the zip, as well as runfiles paths if they exist. Manifests also contain information about the relationships between its own web paths, and those of direct dependencies.
Canonical build target for this rule, e.g. @com_google_javascript_closure_library//closure/goog
Map of files outputted by this build rule target in deterministic reverse topological order w.r.t. links. Within this message, the webfile.webpath key is unique with caveats described below; however, it may be genuinely duplicated across multiple WebfilesInfo messages, in which case the last entry wins.
Relationships between absolute web paths in deterministic reverse topological order. Files become linked when they import each other. This field is also aggressively populated by runtime_deps. For each link.key, a webfile.webpath should exist.
Relationships between absolute web paths that have been eliminated, in no particular deterministic order. This happens when the compiler does things like inline files. For each unlink.key, a webfile.webpath should exist. This field will not contradict link.
Information produced by each webfiles() target.
Canonical build target for this rule, e.g. @com_google_javascript_closure_library//closure/goog
List of srcs associated with webfiles() target.
Configuration required to start a webfiles server.
Canonical build target for this rule, e.g. //myapp/components/foo
HostAndPort on which to listen for requests.
Paths of Webfiles proto manifests relative to TEST_SRCDIR.
Bindings for serving runfiles or other files outside the build graph.
If true, dev server process will fail if bind port is in use, rather than incrementing the port until one can be found.
If true, don't spawn the thread that monitors the file system for changes.
Information about a single entry in the src list.
Used in:
Blaze execroot path. This can be used by ctx.action to read the file from disk. But please note that this file is probably only valid for the specific target that generated it.
Long path of file relative to TEST_SRCDIR. This is used by WebfilesServer to read the file.
Absolute path of file on web server.