Many 4D developers leverage the power of third-party components found on GitHub, particularly those listed in the 4d-component topic. 4D 20 R6 introduces a fantastic new feature: directly integrating these components within the Component Manager.

This blog post dives into the details, making your development process easier and more efficient.

Many 4D components are available on GitHub, whether developed by third parties or created by yourself.
This platform offers a simple way of distributing components: releases.
Before continuing, we suggest you read the post on Component Manager to become more comfortable with the concepts described below.

Automatically download repository releases

The Component Manager not only integrates local components but also automatically retrieves components stored in repository releases.

In the project Dependencies dialog, GitHub components are easily distinguishable from local ones by a small icon next to the component location indication.

Here’s how it works:

1. Compress your component into a ZIP format.
2. Name the archive using the same name as the repository.
3. Integrate it into a repository release.

For example, this process can be automated using 4D code or GitHub Actions. Once done, declare the component in your project’s dependencies.json file:

{
    "dependencies": {
        "myComponent": {
            "github": "anyAccount/myComponent"
        }
    }
}

Restart the project, and the component will load automatically. It’s that simple!

Tags and semantic versions

When you create a release in the repository, you specify a tag and a version.

Tags are texts that uniquely reference a release. In the dependencies.json file, you can indicate the release tag you want to use in your project. For example :

{
    "dependencies": {
        "myComponent": {
            "github": "anyAccount/myComponent",
            "tag": "textTag"
        }
    }
}

In the same way, a release is identified by a version. The versioning system is based on the Semantic Versioning concept, which is the most commonly used. Each version number is determined as follows: majorNumber.minorNumber.patchNumber. In the same way as for tags, you can indicate the version of the component you wish to use in your project, as in this example:

{
    "dependencies": {
        "myComponent": {
            "github": "anyAccount/myComponent",
            "version": "2.1.3"
        }
    }
}

The version is used to define which versions can be used. Here are a few examples:

• “latest”: the version with the “latest” badge in repository releases.
• “*”: the latest version released.
• “1.*”: all versions of major version 1.
• “1.2.*”: all patches of minor version 1.2.
• “^1.2.3” or “>=1.2.3”: the latest version 1, starting with the 1.2.3 version.
• “~1.2.3” or “>1.2.3”: the latest major version 1, starting with the version just after 1.2.3.
• “<=1.2.3”: the latest version until the 1.2.3 one.
• “1.0.0 – 1.2.3” or “>=1.0.0 <=1.2.3”: version between 1.0.0 and 1.2.3.

• “<1.2.3 || >=2”: version that is not between 1.2.3 and 2.0.0.

If you do not specify a tag or a version, 4D automatically retrieves the “latest” version.

Private repositories

If you want to integrate a component located in a private repository, you need to tell 4D to use a connection token to access it. To do this, create a “classic” token with access rights to “repo” in your GitHub account. Then, insert the generated key in your environment4d.json file.
Here is an example of environment4d.json file:

{
    "github": {
        "token": "ghp_a0B1cDEf2gHi3JKl4mNo5P6qRST7UvW8x9yZ"
    }
}

This new feature simplifies work with 4D components. We’re confident you’ll find this integration valuable. It promotes a more efficient development process and leverages a huge collaborative power for 4D developers. Feel free to share your 4D components in GitHub repositories and badge them with the 4d-component topic. You will join the great community of 4D component developers and be referenced in the 4D Components list.
Feel free to share your feedback!