Gathering detailed insights and metrics for protobufjs-cli-stacey
Gathering detailed insights and metrics for protobufjs-cli-stacey
Gathering detailed insights and metrics for protobufjs-cli-stacey
Gathering detailed insights and metrics for protobufjs-cli-stacey
Protocol Buffers for JavaScript & TypeScript.
npm install protobufjs-cli-stacey
Typescript
Module System
Node Version
NPM Version
protobufjs: v7.5.3
Updated on May 28, 2025
protobufjs: v7.5.2
Updated on May 14, 2025
protobufjs: v7.5.1
Updated on May 08, 2025
protobufjs: v7.5.0
Updated on Apr 15, 2025
protobufjs-cli: v1.2.0
Updated on Apr 15, 2025
protobufjs: v7.4.0
Updated on Aug 22, 2024
JavaScript (99.78%)
TypeScript (0.22%)
Total Downloads
0
Last Day
0
Last Week
0
Last Month
0
Last Year
0
NOASSERTION License
10,277 Stars
942 Commits
1,437 Forks
170 Watchers
38 Branches
109 Contributors
Updated on Jul 12, 2025
Latest Version
7.1.50
Package Id
protobufjs-cli-stacey@7.1.50
Unpacked Size
102.17 kB
Size
26.26 kB
File Count
31
NPM Version
6.11.3
Node Version
10.17.0
Cumulative downloads
Total Downloads
Last Day
0%
NaN
Compared to previous day
Last Week
0%
NaN
Compared to previous week
Last Month
0%
NaN
Compared to previous month
Last Year
0%
NaN
Compared to previous year
Command line interface (CLI) for protobuf.js.
This can be used to translate between file formats and to generate static code as well as TypeScript definitions.
Translates between file formats and generates static code.
-t, --target Specifies the target format. Also accepts a path to require a custom target.
json JSON representation
json-module JSON representation as a module
proto2 Protocol Buffers, Version 2
proto3 Protocol Buffers, Version 3
static Static code without reflection (non-functional on its own)
static-module Static code without reflection as a module
-p, --path Adds a directory to the include path.
-o, --out Saves to a file instead of writing to stdout.
--sparse Exports only those types referenced from a main file (experimental).
Module targets only:
-w, --wrap Specifies the wrapper to use. Also accepts a path to require a custom wrapper.
default Default wrapper supporting both CommonJS and AMD
commonjs CommonJS wrapper
amd AMD wrapper
es6 ES6 wrapper (implies --es6)
closure A closure adding to protobuf.roots where protobuf is a global
-r, --root Specifies an alternative protobuf.roots name.
-l, --lint Linter configuration. Defaults to protobuf.js-compatible rules:
eslint-disable block-scoped-var, no-redeclare, no-control-regex, no-prototype-builtins
--es6 Enables ES6 syntax (const/let instead of var)
Proto sources only:
--keep-case Keeps field casing instead of converting to camel case.
Static targets only:
--no-create Does not generate create functions used for reflection compatibility.
--no-encode Does not generate encode functions.
--no-decode Does not generate decode functions.
--no-verify Does not generate verify functions.
--no-convert Does not generate convert functions like from/toObject
--no-delimited Does not generate delimited encode/decode functions.
--no-beautify Does not beautify generated code.
--no-comments Does not output any JSDoc comments.
--force-long Enfores the use of 'Long' for s-/u-/int64 and s-/fixed64 fields.
--force-number Enfores the use of 'number' for s-/u-/int64 and s-/fixed64 fields.
--force-message Enfores the use of message instances instead of plain objects.
usage: pbjs [options] file1.proto file2.json ... (or pipe) other | pbjs [options] -
For production environments it is recommended to bundle all your .proto files to a single .json file, which minimizes the number of network requests and avoids any parser overhead (hint: works with just the light library):
$> pbjs -t json file1.proto file2.proto > bundle.json
Now, either include this file in your final bundle:
1var root = protobuf.Root.fromJSON(require("./bundle.json"));
or load it the usual way:
1protobuf.load("bundle.json", function(err, root) { 2 ... 3});
Generated static code, on the other hand, works with just the minimal library. For example
$> pbjs -t static-module -w commonjs -o compiled.js file1.proto file2.proto
will generate static code for definitions within file1.proto
and file2.proto
to a CommonJS module compiled.js
.
ProTip! Documenting your .proto files with /** ... */
-blocks or (trailing) /// ...
lines translates to generated static code.
Generates TypeScript definitions from annotated JavaScript files.
-o, --out Saves to a file instead of writing to stdout.
-g, --global Name of the global object in browser environments, if any.
--no-comments Does not output any JSDoc comments.
Internal flags:
-n, --name Wraps everything in a module of the specified name.
-m, --main Whether building the main library without any imports.
usage: pbts [options] file1.js file2.js ... (or) other | pbts [options] -
Picking up on the example above, the following not only generates static code to a CommonJS module compiled.js
but also its respective TypeScript definitions to compiled.d.ts
:
$> pbjs -t static-module -w commonjs -o compiled.js file1.proto file2.proto
$> pbts -o compiled.d.ts compiled.js
Additionally, TypeScript definitions of static modules are compatible with their reflection-based counterparts (i.e. as exported by JSON modules), as long as the following conditions are met:
new SomeMessage(...)
, always use SomeMessage.create(...)
because reflection objects do not provide a constructor.MyMessage.MyEnum
instead of root.lookup("MyMessage.MyEnum")
).For example, the following generates a JSON module bundle.js
and a bundle.d.ts
, but no static code:
$> pbjs -t json-module -w commonjs -o bundle.js file1.proto file2.proto
$> pbjs -t static-module file1.proto file2.proto | pbts -o bundle.d.ts -
While using .proto files directly requires the full library respectively pure reflection/JSON the light library, pretty much all code but the relatively short descriptors is shared.
Static code, on the other hand, requires just the minimal library, but generates additional source code without any reflection features. This also implies that there is a break-even point where statically generated code becomes larger than descriptor-based code once the amount of code generated exceeds the size of the full respectively light library.
There is no significant difference performance-wise as the code generated statically is pretty much the same as generated at runtime and both are largely interchangeable as seen in the previous section.
Source | Library | Advantages | Tradeoffs |
---|---|---|---|
.proto | full | Easily editable Interoperability with other libraries No compile step | Some parsing and possibly network overhead |
JSON | light | Easily editable No parsing overhead Single bundle (no network overhead) | protobuf.js specific Has a compile step |
static | minimal | Works where eval access is restrictedFully documented Small footprint for small protos | Can be hard to edit No reflection Has a compile step |
Both utilities can be used programmatically by providing command line arguments and a callback to their respective main
functions:
1var pbjs = require("protobufjs/cli/pbjs"); // or require("protobufjs/cli").pbjs / .pbts 2 3pbjs.main([ "--target", "json-module", "path/to/myproto.proto" ], function(err, output) { 4 if (err) 5 throw err; 6 // do something with output 7});
License: BSD 3-Clause License
No vulnerabilities found.
Reason
25 commit(s) out of 30 and 0 issue activity out of 30 found in the last 90 days -- score normalized to 10
Reason
all last 30 commits are reviewed through GitHub
Reason
no vulnerabilities detected
Reason
update tool detected
Details
Reason
no dangerous workflow patterns detected
Reason
license file detected
Details
Reason
no binaries found in the repo
Reason
dependency not pinned by hash detected -- score normalized to 7
Details
Reason
branch protection is not maximal on development and all release branches
Details
Reason
no badge detected
Reason
non read-only tokens detected in GitHub workflows
Details
Reason
security policy file not detected
Reason
project is not fuzzed
Score
Last Scanned on 2022-08-15
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More