Automate your release process with 🛳 Ship.js

Interesting work by Algolia, to more easily release new versions of your packages:

When releasing, you go through something like the following:

  • Update the version in package.json
  • Update the changelog
  • Actually release it (e.g. yarn build && yarn publish)
  • Create a git tag

As such as manual process is prone to errors, they’ve developed 🛳 Ship.js, by which you can automate the process:

  1. Run shipjs prepare which will figure out the next version and create a PR
  2. Manually review the PR
  3. Run shipjs release to trigger a release and set up the proper tags and such

Installation per npm/yarn:

yarn add -D shipjs

🛳 Ship.js →

Find the cost of adding a npm package to your bundle with BundlePhobia

Ever wondered what the (size) impact of adding an NPM package to your project is? BundlePhobia is a tool that does not only that, it also recommends you other similar packages that have a lesser load.

This thing lets you understand the performance cost of npm install‘ing a new npm package before actually adding it to your bundle.

BundlePhobia →

Internal classes in PHP

As a (PHP) package developer, you sometimes have classes that are meant for internal use – inside the package itself – only. PHP has no built-in solution for this, but using a DocBlock Tag one can indicate its intended use. As Nuno Maduro explains:

Maybe in the future, the PHP language will have the internal class access modifier, it would prevent people from using internal classes from your library. Meanwhile, the PHP @internal tag can be used to denote that the associated class/method is internal to the library. It’s supported by PHPStorm and it warns people that those classes/methods are not meant to be used

Internal classes in PHP →

Via Freek (who recently redesigned his blog by the way)

The Economics of Open Source // Introducing Entropic, a federated package registry

At JSConf EU 2019, CJ Silverio – former CTO at NPM Inc – gave this talk on why a VC-funded private package registry (read: the one ran by NPM Inc) holds many dangers.

The JS package commons is in the hands of a for-profit entity. We trust NPM Inc with our shared code, but we have no way to hold NPM Inc accountable for its behavior. A trust-based system cannot function without accountability, but somebody still has to pay for the servers. How did we get here, and what should JavaScript do now?

At the end of the talk she announced Entropic, a federated package registry for anything; but mostly JavaScript.

Entropic assumes many registries co-existing and interoperating as a part of your normal workflow. All Entropic packages are namespaced, and a full Entropic package spec also includes the hostname of its registry.

Entropic: a federated package registry for anything →

Selling Composer Packages through “Private Packagist for Vendors”

Nice new addition by Packagist:

If you’re selling PHP packages, the easiest way to offer Composer package installation to your customers is now “Private Packagist for Vendors”. You get a unique URL and authentication token for each customer and they can use these in their composer.json file to install your packages. Especially if you’re still sending zip files to your customers, there is really no reason anymore not to to offer Composer installations.

You can use their our API to integrate “Private Packagist for Vendors” with your existing PHP package shop: Create a customer, grant the customer access to the package, and then get the info needed to send to the customer — all using their API.

// 1. Create Customer
$customer = $client
    ->customers()
    ->create('Acme Web Inc.');

// 2. Grant access to package for customer
$client->customers()->addOrUpdatePackages(
    $customer['id'],
    [[
        'name' => 'my-vendor/cool-package',
        'versionConstraint' => '^1.0',
        'expirationDate' => strtotime('+1 year'),
    ]]
);

// 3. Get info to send to user
$info = $client->customers()->show($customer['id']);

// …
//    'composerRepository' => [
//        'url' => 'https://my-vendor.repo.packagist.com',
//        'user' => 'token',
//        'token' => 'a6addb89a67b2822d352d113',
// …

As you can see in the code above, customers their access can be locked to specific versions and also limited in time.

Packagist Blog: Introducing Private Packagist for Vendors →
Private Packagist for Vendors →

Private Packagist

Mid-December Nils Adermann – Co-Founder of Packagist Conductors & Creator of Composer for PHP – announced Private Packagist.

Being a hosted service, setting up your own Composer package repository on Private Packagist is done with a few clicks. No matter if your private source code is hosted on GitHub, GitLab, Bitbucket, any of their on-premise solutions, or in any other Git, Mercurial, or Subversion repository, Private Packagist can immediately access your code after setting up your credentials to make it available for installation through Composer.

A few years ago I tried setting up Satis, but that didn’t quite work out. Private Packagist would’ve been handy back then 🙂

Private Packagist →
Introducing Private Packagist →

Composer – Dependency Manager for PHP

Composer is a tool for dependency management in PHP. It allows you to declare the dependent libraries your project needs and it will install them in your project for you.

Think npm install but then for PHP

{
    "require": {
        "monolog/monolog": "1.2.*"
    }
}
$ composer install

Plays nice with packages that support PSR-0 autoloading. Packages can be found on packagist.org

Composer →