Blog

Intro to box.json

Nathaniel Francis February 26, 2015

Spread the word

Nathaniel Francis

February 26, 2015

Spread the word


Share your thoughts

Package management = development++

Package management is one of the key aspects to CommandBox development. Going out to ForgeBox and uploading a package in seconds is a major boost to CFML development efficiency and extensibility.

All about that box.json

To make package management work in the CFML community, we need standards: a way to categorize packages, log dependencies, and register packages with ForgeBox. The file that handles these aspects is box.json. Every package uploaded to ForgeBox requires one. They communicate the basic information from name, slug, and author - to really detailed information like dependencies, CFML engine compatibility, licensing, CFC type and much, much more!!!

K.I.S.S. (Keep It Simple, Silly)

Please don't lose it on the "much, much more!!!". Just because you can do amazing things with the box.json doesn't mean you have to.

When in doubt, keep it simple.

It is a good idea to add (at a minimum), these attributes to your box.json.

{
    "name" : "Ortus Awesome",
    "slug" : "ort-awe",
    "version" : "1.0",
}

I made a fictitious "Ortus Awesome" package, gave it the unique ForgeBox slug "ort-awe" (something ForgeBox checks when you register the package), and made it version 1.0 - a very basic alpha version.

These three attributes are a good minimum requirement because:

  • name is what you'd call your package
  • slug allows developers to find/upload if via ForgeBox
  • version is helpful for you both: allows you to make updates clearly (by increasing the version number) and for developers to see that out on ForgeBox.

Future Proof

By populating your package's box.json file with these attributes, be assured that you have the necessary items to keep your package relevant both now and going forward. Future versions of ForgeBox and CommandBox will leverage these attributes, and the box.json as a whole more and more.

Add Your Comment

Recent Entries

MatchBox and WebAssembly: Running BoxLang in the Browser and at the Edge

MatchBox and WebAssembly: Running BoxLang in the Browser and at the Edge

The MatchBox open beta is live at https://boxlang.ortusbooks.com/boxlang-framework/matchbox, and it brings something genuinely new to the BoxLang ecosystem: a path into WebAssembly.

That means BoxLang code can now move into browser applications, static-site deployments, edge runtimes, and WASI-style containers - without requiring a JVM. The feature is still beta, but the core direction is already useful: write BoxLang, compile it with MatchBox, and ship the generated WASM artifact to wherever a small portable runtime makes sense.

Jacob Beers
Jacob Beers
June 04, 2026
One Language, Every Runtime: BoxLang Expands Beyond the Server

One Language, Every Runtime: BoxLang Expands Beyond the Server

Discover how BoxLang’s multi-runtime architecture helps developers build beyond the server with support for serverless functions, desktop applications, CI/CD workflows, Java integrations, containers, runtime management, and more.

Maria Jose Herrera
Maria Jose Herrera
June 04, 2026
BoxLang 1.14.0 : BoxSet is Here: BoxLang's New First-Class Set Type

BoxLang 1.14.0 : BoxSet is Here: BoxLang's New First-Class Set Type

BoxLang 1.14.0 ships something that JVM developers have wanted for a long time: a true first-class Set type baked directly into the language. Not a wrapper you reach for manually, not a createObject( "java", "java.util.HashSet" ) incantation you paste from a Stack Overflow answer years ago. A real BoxSet with literal syntax, operator overloads, a full functional pipeline, change listeners, JSON serialization, and deep Java interop.

Luis Majano
Luis Majano
June 03, 2026