Code boundary management for TypeScript projects
Last updated 21 days ago by smikula .
MIT · Repository · Bugs · Original npm · Tarball · package.json
$ cnpm install good-fences 
SYNC missed versions from official npm registry.


"Good fences make good neighbors." — Robert Frost, Mending Wall

What is good-fences?

Good-fences is a tool that allows you to segment a TypeScript project into conceptual areas and manage dependencies between those areas.

This is mostly a concern for large projects with many people working on them, where it is impossible for every developer to have a wholistic understanding of the entire codebase. JavaScript's module system is a specialized form of anarchy because any file can import any other file, possibly allowing access to code that was really meant to be an internal implementation detail of some larger system. Other languages have concepts like DLL boundaries and the internal keyword to mitigate this. Good-fences provides a way to enforce similar boundaries in the TypeScript world.

Getting started

  1. Install: npm install -g good-fences

  2. Configure with one or more fence.json files (see below).

  3. Run: gf [options]

    Or run good-fences programmatically via the API:

    import { run } from 'good-fences';

Also see the sample project which demonstrates how fences can be configured. To run good-fences against the sample, just clone this repository and run npm run sample.

Configuring good-fences

Good-fences is configured by creating fence.json files throughout your project's directory structure. This configuration file defines a "fence" around that directory (and any subdirectories). Within a fenced directory, modules may import each other without restriction—fences only control what passes in or out of them. Fences may be nested, so that a given directory may have two or more configuration files that apply to it.

A typical fence.json might look like the following.

    "tags": [ "tag1", "tag2" ],
    "exports": [
            "modules": "internals/*",
            "accessibleTo": "tag3"
    "imports": [
    "dependencies": [


The tags property can specify one or more tags to apply to all modules under this config's subdirectory. Tags are a way of defining a class of files; for example you might tag all your UI components with 'view', or you might have very granular tags for different areas within your application. (Or both!) Tags are used by the other config options to scope which modules are accessible to other modules.


The exports property specifies what modules are accessible from the directory. In other words, it allows you to keep private modules private. If fence.json contains an exports definition, then in order for any module outside the directory to import a module under the directory, there must be a matching export rule. If there is no exports definition, then all modules are considered exported.

The exports property is an array of rules. A rule consists of:

  • The modules glob string which resolves to one or more modules within the directory. (An asterisk ("*") indicates all modules under the directory.)
  • An optional accessibleTo property which is a tag (or array of tags) to which these modules are accessible.
  • If accessibleTo is not defined then there is no restriction on where these modules may be imported. (As a convenience, you can just provide a string as an export rule if you don't need to specify accessibleTo.)

This is best demonstrated with an example:

"exports": [
        "modules": "views/**/*",
        "accessibleTo": "view"
        "modules": "data/store",
        "accessibleTo": [ "data", "view" ]
  • The index module is accessible to all modules.
  • Modules under the /view directory are accessible to any module tagged with 'view'.
  • The data/store module is accessible to any module tagged with 'data' or 'view'.


The imports property specifies what modules may be imported by modules in the directory. This allows you to control your module graph by restricting unwanted dependencies. (Note that imports applies to your project code; for external dependencies see dependencies below.) If fence.json contains an imports definition, then only imports with the given tags will be allowed. If there is no imports definition, then any module is free to be imported.

The imports property is an array of tags:

"imports": [

In this case, modules tagged with either 'tag1' or 'tag2' may be imported.


The dependencies property specifies what external dependencies (i.e. those installed under node_modules) may be imported by modules in the directory. If fence.json contains an dependencies definition, then only matching dependencies are allowed. (If there is no dependencies definition, then any dependency is free to be imported.)

The dependencies property is an array of dependencies to allow. Each element can be a simple glob string or an object that allows for more configuration.

"dependencies": [
        "dependency": "dependency3",
        "accessibleTo": "tag3"
  • The index of dependency1 may be imported.
  • Anything under dependency2/lib may be imported.
  • The index of dependency3 may be imported, but only by modules with the 'tag3' tag.



Specify the tsconfig file to use for your project.

Default CLI API
./tsconfig.json --project <string>
-p <string>
project: string

Root Directory

Specify the project root directory.

Default CLI API
process.cwd() --rootDir <string>
-r <string>
rootDir: string

Return value

When running good-fences via the API, the results are returned in a structure like the following:

    "errors": [
            "message": "The error message",
            "sourceFile": "The source file where the error was encountered",
            "rawImport": "The offending import",
            "fencePath": "The fence whose rule was violated",
            "detailedMessage": "A human-friendly message that includes all of the above"
    "warnings": [
            "message": "The warning message",
            "fencePath": "The fence which generated the warning",
            "detailedMessage": "A human-friendly message that includes all of the above"

Current Tags

  • 0.9.0                                ...           latest (21 days ago)

14 Versions

  • 0.9.0                                ...           21 days ago
  • 0.8.0                                ...           2 months ago
  • 0.7.0                                ...           3 months ago
  • 0.6.0                                ...           4 months ago
  • 0.5.1                                ...           a year ago
  • 0.5.0                                ...           a year ago
  • 0.4.0                                ...           a year ago
  • 0.3.3                                ...           2 years ago
  • 0.3.2                                ...           2 years ago
  • 0.3.1                                ...           2 years ago
  • 0.3.0                                ...           2 years ago
  • 0.2.0                                ...           2 years ago
  • 0.1.1                                ...           2 years ago
  • 0.1.0                                ...           2 years ago
Maintainers (1)
Today 0
This Week 0
This Month 3
Last Day 0
Last Week 1
Last Month 56
Dependencies (3)
Dev Dependencies (4)
Dependents (0)

Copyright 2014 - 2016 © |