variants.yml

# The general idea is that maintainers would publish "meta-packages" that would describe
# where to find the specific implementations for a given set of parameters (defined by a
# template string). The template string would be resolved based on the known parameter (after
# checking that the active parameters are compatible with the supported ones), and the package
# used instead of the original one.
#
# One nice thing is that it would degrade nicely on package managers that wouldn't support this
# spec: they would simply ignore the `variants` field, and thus would use the package itself,
# with everything it contains - including a potential fallback.
#
# The main tricky part at the moment is to figure out how to cascade parameters: for example,
# should the top-level consumer have the ability to add parameters (for instance to select a
# minified variant)? Or should it be left to the direct dependent? Should parameters be
# inherited? Explicitly, or implicitly? This kind of things.
{
    "name": "prisma-build",
    "version": "1.0.0",

    "variants": {
        # Which package to fetch?
        "pattern": "prisma-build-%platform-%napi",

        # What are the supported values?
        # Follows the same idea as GH Actions' matrix
        "matrix": {
            "platform": {
                "candidates": [
                    "darwin",
                    "win32"
                ]
            },
            "napi": {
                "candidates": [
                    "5",
                    "6"
                ]
            }
        },

        # Some extra supported parameters that don't compose
        "include": [{
            "platform": "wasm",
            "napi": null
        }],

        # Some combinations that specifically aren't supported
        "exclude": [{
            "platform": "win32",
            "napi": 5
        }],

        # The package manager would check what are the current properties,
        # and would select the matrix entry that match. By default some
        # properties (such as "platform" or "napi") would have predefined
        # values based on the environment, but the user would be able to
        # define their own, and override them on a per-package basis:
        #
        # {
        #   "dependenciesMeta": {
        #     "prisma-build": {
        #       "parameters": {
        #         "platform": "wasm"
        #       }
        #     }
        #   }
        # }
        #
        # This prisma-build-sources could itself have different flavors, for
        # example to include documentation or not.
        "fallback": "prisma-build-sources"
    }
}