<commit_before># Fiddler

    Note: this project is experimental. Please provide feedback!

Fiddler introduces a maintainable approach to managing dependencies for
multiple packages in a single repository, without losing the benefits of having
explicit dependencies for each separate package.

Repositories managed with Fiddler contain two kinds of packages:

1. Composer packages defined by a single global `composer.json`.
2. Many Fiddler packages in sub-folders of the project, each with its own
   `fiddler.json`, a simplified `composer.json` file.

Dependencies in Fiddler can be on either a third party Composer package or a
Fiddler package contained in the project.

Fiddler's build step generates `vendor/autoload.php` files for each package
that allow access to the explicitly specified dependencies.

Fiddler draws inspiration from Google [Blaze/Bazel](http://bazel.io/) and
Facebook [Buck](http://facebook.github.io/buck/) implementing a single
monolithic repository for whole projects/company. Its the missing piece for
the monolithic repository workflow using PHP and Composer.

More details about reasoning on <NAME>'s blog:

- [On Monlithic Repositories](http://gregoryszorc.com/blog/2014/09/09/on-monolithic-repositories/)
- [Notes from Facebooks Developer Infrastructure at Scale F8 talk](http://gregoryszorc.com/blog/2015/03/28/notes-from-facebook's-developer-infrastructure-at-scale-f8-talk/)

## Usage

Fiddler offers a very simple command line interface for now:

    $ php fiddler.phar build

Run this in project root, next to the `composer.json` file.

The following steps are performed by building:

1. It detects `fiddler.json` files in subdirectories except `vendor/` and marks
   them as roots of packages.
2. It then fetches all composer packages from the locally installed packages.
3. Finally for each package with `fiddler.json` it generates a
   `vendor/autoload.php` file using all the dependencies defined in that
   package from either other Fiddler or Composer packages.

## Benefits

1. You can just `require "vendor/autoload.php;` in every package as if you were using Composer.
   Only autoloads from the `fiddler.json` are included, which means all dependencies must be explicitly
   specified.
2. No one-to-one git repository == composer package requirement anymore,
   increasing productivity using Google/Facebook development model.
3. No composer.lock/Pull Request issues that block your productivity with multi repository projects.
4. If you commit `vendor/` no dependency on Github and Packagist anymore for fast builds.
5. Much higher Reproducibility of builds
6. Not yet: Detect packages that changed since a given commit and their dependants to allow efficient
   build process on CI systems (only test packages that changed, only regenerate assets for packages that changed, ...)

## Description

This project assumes you have a single monolithic repository containing
multiple packages as well as third party dependencies using Composer.

You would create a `composer.json` file in the root of your project and use
this single source of vendor libraries accross all your own packages.

This sounds counter-intuitive to the Composer approach at first, but
it simplifies dependency management for a big project massively. Usually
if you are using a composer.json per package, you have mass update sprees
where you upate some basic library like "symfony/dependency-injection" in
10-20 packages or worse, have massively out of date packages and
many different versions everywhere.

Then every of your own package contains a `fiddler.json` using almost
the same syntax as Composer:

    {
        "deps": [
            "components/Foo"
            "vendor/symfony/symfony"
        ],
        "autoload": {
            "psr-0": {"Foo\\": "src/"}
        }
    }

You can then run `fiddle build` in the root directory next to composer.json and
it will detect all packages, generate a custom autoloader for each one by
simulating `composer dump-autoload` as if a composer.json were present.

Fiddle will resolve all dependencies (without version constraints, because it
is assumed the code is present in the correct versions in a monolithic
repository).<commit_msg>Fix minor typos and grammatical errors.<commit_after># Fiddler

    Note: this project is experimental. Please provide feedback!

Fiddler introduces a maintainable approach to managing dependencies for
multiple packages in a single repository, without losing the benefits of having
explicit dependencies for each separate package.

Repositories managed with Fiddler contain two kinds of packages:

1. Composer packages defined by a single global `composer.json`.
2. Many Fiddler packages in sub-folders of the project, each with its own
   `fiddler.json`, a simplified `composer.json` file.

Dependencies in Fiddler can be either a third party Composer package or a
Fiddler package contained in the project.

Fiddler's build step generates `vendor/autoload.php` files for each package
that allow access to the explicitly specified dependencies.

Fiddler draws inspiration from Google [Blaze/Bazel](http://bazel.io/) and
Facebook [Buck](http://facebook.github.io/buck/) implementing a single
monolithic repository for whole projects/company. It's the missing piece for
the monolithic repository workflow using PHP and Composer.

More details about reasoning on <NAME>'s blog:

- [On Monlithic Repositories](http://gregoryszorc.com/blog/2014/09/09/on-monolithic-repositories/)
- [Notes from Facebooks Developer Infrastructure at Scale F8 talk](http://gregoryszorc.com/blog/2015/03/28/notes-from-facebook's-developer-infrastructure-at-scale-f8-talk/)

## Usage

Fiddler offers a very simple command line interface for now:

    $ php fiddler.phar build

Run this in project root, next to the `composer.json` file.

The following steps are performed by building:

1. It detects `fiddler.json` files in subdirectories except `vendor/` and marks
   them as roots of packages.
2. It then fetches all composer packages from the locally installed packages.
3. Finally for each package with `fiddler.json` it generates a
   `vendor/autoload.php` file using all the dependencies defined in that
   package from either other Fiddler or Composer packages.

## Benefits

1. You can just `require "vendor/autoload.php;` in every package as if you were using Composer.
   Only autoloads from the `fiddler.json` are included, which means all dependencies must be explicitly
   specified.
2. No one-to-one git repository == composer package requirement anymore,
   increasing productivity using Google/Facebook development model.
3. No composer.lock/Pull Request issues that block your productivity with multi-repository projects.
4. If you commit `vendor/` no dependency on Github and Packagist anymore for fast builds.
5. Much higher Reproducibility of builds.
6. Not yet: Detect packages that changed since a given commit and their dependents to allow efficient
   build process on CI systems (only test packages that changed, only regenerate assets for packages that changed, ...)

## Description

This project assumes you have a single monolithic repository containing
multiple packages as well as third-party dependencies using Composer.

You would create a `composer.json` file in the root of your project and use
this single source of vendor libraries accross all of your own packages.

This sounds counter-intuitive to the Composer approach at first, but
it simplifies dependency management for a big project massively. Usually
if you are using a composer.json per package, you have mass update sprees
where you upate some basic library like "symfony/dependency-injection" in
10-20 packages or worse, have massively out of date packages and
many different versions everywhere.

Then, each of your own package contains a `fiddler.json` using almost
the same syntax as Composer:

    {
        "deps": [
            "components/Foo"
            "vendor/symfony/symfony"
        ],
        "autoload": {
            "psr-0": {"Foo\\": "src/"}
        }
    }

You can then run `fiddler build` in the root directory next to composer.json and
it will detect all packages, generate a custom autoloader for each one by
simulating `composer dump-autoload` as if a composer.json were present.

Fiddler will resolve all dependencies (without version constraints, because it
is assumed the code is present in the correct versions in a monolithic
repository).
{'fraction_non_alphanumeric': 0.058489225668955716, 'fraction_numerical': 0.008051148472649775, 'mean_word_length': 4.194956949569495, 'pattern_counts': {'":': 8, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 8, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3328771', 'n_tokens_mistral': 2243, 'n_tokens_neox': 2121, 'n_words': 1092}