Gathering detailed insights and metrics for broccoli
Gathering detailed insights and metrics for broccoli
Gathering detailed insights and metrics for broccoli
Gathering detailed insights and metrics for broccoli
broccoli-plugin
Base class for all Broccoli plugins
broccoli-persistent-filter
broccoli filter but with a persistent cache
broccoli-funnel
Broccoli plugin that allows you to filter files selected from an input node down based on regular expressions.
broccoli-source
Broccoli plugin for referring to source directories on the file system
Browser compilation library – an asset pipeline for applications that run in the browser
npm install broccoli
Typescript
Module System
Min. Node Version
Node Version
NPM Version
72.7
Supply Chain
85.3
Quality
74
Maintenance
50
Vulnerability
96.5
License
v3.5.2
Updated on May 03, 2021
v3.5.0
Updated on Dec 07, 2020
Input node change tracking
Updated on Aug 15, 2019
Node version change, Rebuild memoization, and Watcher changes
Updated on May 20, 2019
TypeScript support
Updated on Mar 20, 2019
ES Modules, Export function & Environment support
Updated on Mar 07, 2019
JavaScript (58.7%)
TypeScript (37.66%)
HTML (3.58%)
Shell (0.06%)
Total Downloads
50,093,318
Last Day
16,129
Last Week
215,319
Last Month
896,280
Last Year
7,231,279
MIT License
3,325 Stars
965 Commits
216 Forks
69 Watchers
19 Branches
52 Contributors
Updated on Apr 23, 2025
Minified
Minified + Gzipped
Latest Version
3.5.2
Package Id
broccoli@3.5.2
Size
44.79 kB
NPM Version
6.14.11
Node Version
14.16.0
Published on
May 03, 2021
Cumulative downloads
Total Downloads
24
34
A fast, reliable asset pipeline, supporting constant-time rebuilds and compact build definitions. Comparable to the Rails asset pipeline in scope, though it runs on Node and is backend-agnostic.
For more information and guides/documentation, checkout broccoli.build
For background and architecture, see the introductory blog post.
For the command line interface, see broccoli-cli.
1npm install --save-dev broccoli 2npm install --global broccoli-cli
A Brocfile.js
file in the project root contains the build specification. It
should export a function that returns a tree. Note: the Brocfile historically
could export a tree/string directly, however this is now deprecated in favor
of a function that can receive options
A tree can be any string representing a directory path, like 'app'
or
'src'
. Or a tree can be an object conforming to the Plugin API
Specification. A Brocfile.js
will usually
directly work with only directory paths, and then use the plugins in the
Plugins section to generate transformed trees.
The following simple Brocfile.js
would export the app/
subdirectory as a
tree:
1export default () => 'app';
With that Brocfile, the build result would equal the contents of the app
tree in your project folder. For example, say your project contains these
files:
app
├─ main.js
└─ helper.js
Brocfile.js
package.json
…
Running broccoli build the-output
(a command provided by
broccoli-cli) would generate
the following folder within your project folder:
the-output
├─ main.js
└─ helper.js
The function that is exported from module.exports
is passed an options hash by Broccoli
that can be used when assembling the build.
The options hash is populated by the CLI environment when running broccoli build
or broccoli serve
. It currently only accepts a single option --environment
, which
is passed as env
in the options
hash.
Additionally --prod
and --dev
are available aliases to --environment=production
and --environment=development
respectively.
options
:
env
: Defaults to development
, and can be overridden with the CLI argument --environment=X
For example:
1export default (options) => { 2 // tree = ... assemble tree 3 4 // In production environment, minify the files 5 if (options.env === 'production') { 6 tree = minify(tree); 7 } 8 9 return tree; 10}
A Brocfile.ts
can be used in place of a Brocfile.js
and Broccoli will automatically parse this
through ts-node to provide TypeScript
support. This allows developers to leverage type information when assembling a build pipeline. By default,
Broccoli provides type information for the options object passed to the build function.
1import { BrocfileOptions } from 'broccoli'; 2 3export default (options: BrocfileOptions) => { 4 // tree = ... assemble tree 5 6 // In production environment, minify the files 7 if (options.env === 'production') { 8 tree = minify(tree); 9 } 10 11 return tree; 12}; 13
Typescript by default only allows the ES6 modules import/export
syntax to work
when importing ES6 modules. In order to import a CommonJS module (one that uses require() or module.exports
, you must
use the following syntax:
1import foo = require('foo'); 2 3export = 'bar';
You'll note the syntax is slightly different from the ESM syntax, but reads fairly well.
Brocfile.js
The following Brocfile.js
exports the app/
subdirectory as appkit/
:
1// Brocfile.js 2import Funnel from 'broccoli-funnel'; 3 4export default () => new Funnel('app', { 5 destDir: 'appkit' 6})
Broccoli supports ES6 modules via esm for
Brocfile.js
. Note, TypeScript requires the use of a different syntax, see the TypeScript section above.
You can also use regular CommonJS require
and module.exports
if you prefer, however ESM is the future of Node,
and the recommended syntax to use.
That example uses the plugin broccoli-funnel
.
In order for the import
call to work, you must first put the plugin in your devDependencies
and install it, with
npm install --save-dev broccoli-funnel
With the above Brocfile.js
and the file tree from the previous example,
running broccoli build the-output
would generate the following folder:
the-output
└─ appkit
├─ main.js
└─ helper.js
You can find plugins under the broccoli-plugin keyword on npm.
In addition to using Broccoli via the combination of broccoli-cli
and a Brocfile.js
, you can also use Broccoli programmatically to construct your own build output via the Builder
class. The Builder
is one of the core APIs in Broccoli, and is responsible for taking a graph of Broccoli nodes and producing an actual build artifact (i.e. the output usually found in your dist
directory after you run broccoli build
). The output of a Builder
's build
method is a Promise that resolves when all the operations in the graph are complete. You can use this promise to chain together additional operations (such as error handling or cleanup) that will execute once the build step is complete.
By way of example, let's assume we have a graph of Broccoli nodes constructed via a combination of Funnel
and MergeTrees
:
1// non Brocfile.js, regular commonjs
2const Funnel = require('broccoli-funnel');
3const MergeTrees = require('broccoli-merge-trees');
4
5const html = new Funnel(appRoot, {
6 files: ['index.html'],
7 annotation: 'Index file'
8})
9
10const js = new Funnel(appRoot, {
11 files: ['app.js'],
12 destDir: '/assets',
13 annotation: 'JS Files'
14});
15
16const css = new Funnel(appRoot, {
17 srcDir: 'styles',
18 files: ['app.css'],
19 destDir: '/assets',
20 annotation: 'CSS Files'
21});
22
23const public = new Funnel(appRoot, {
24 annotation: 'Public Files'
25});
26
27const tree = new MergeTrees([html, js, css, public]);
At this point, tree
is a graph of nodes, each of which can represent either an input or a transformation that we want to perform. In other words, tree
is an abstract set of operations, not a concrete set of output files.
In order to perform all the operations described in tree
, we need to do the following:
Builder
instance, passing in the graph we constructed beforebuild
method, which will traverse the graph, performing each operation and eventually writing the output to a temporary folder indicated by builder.outputPath
Since we typically want do more than write to a temporary folder, we'll also use a library called TreeSync
to sync the contents of the temp file with our desired output directory. Finally, we'll clean up the temporary folder once all our operations are complete:
1const { Builder } = require('broccoli'); 2const TreeSync = require('tree-sync'); 3const MergeTrees = require('broccoli-merge-trees'); 4// ...snip... 5const tree = new MergeTrees([html, js, css, public]); 6 7const builder = new Builder(tree); 8 9const outputDir = 'dist'; 10const outputTree = new TreeSync(builder.outputPath, outputDir); 11 12builder.build() 13 .then(() => { 14 // Calling `sync` will synchronize the contents of the builder's `outPath` with our output directory. 15 return outputTree.sync(); 16 }) 17 .then(() => { 18 // Now that we're done with the build, clean up any temporary files were created 19 return builder.cleanup(); 20 }) 21 .catch(err => { 22 // In case something in this process fails, we still want to ensure that we clean up the temp files 23 console.log(err); 24 return builder.cleanup(); 25 });
Shared code for writing plugins.
See docs/node-api.md.
Also see docs/broccoli-1-0-plugin-api.md on how to upgrade from Broccoli 0.x to the Broccoli 1.x API.
broccoli serve
on a production server. While this is
theoretically safe, it exposes a needlessly large amount of attack surface
just for serving static assets. Instead, use broccoli build
to precompile
your assets, and serve the static files from a web server of your choice.#broccolijs
on Freenode. Ask your question and stick around for a few
hours. Someone will see your message eventually.Broccoli was originally written by Jo Liss and is licensed under the MIT license.
The Broccoli logo was created by Samantha Penner (Miric) and is licensed under CC0 1.0.
No vulnerabilities found.
Reason
no dangerous workflow patterns detected
Reason
no binaries found in the repo
Reason
license file detected
Details
Reason
Found 8/25 approved changesets -- score normalized to 3
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
dependency not pinned by hash detected -- score normalized to 0
Details
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
35 existing vulnerabilities detected
Details
Score
Last Scanned on 2025-06-30
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 MoreLast Day
-2.5%
16,129
Compared to previous day
Last Week
-8.3%
215,319
Compared to previous week
Last Month
2.4%
896,280
Compared to previous month
Last Year
1.1%
7,231,279
Compared to previous year