Add composer.json.in to ext/skeleton for PIE support

[asgrim]

Pending acceptance of RFC https://wiki.php.net/rfc/adopt_pie_deprecate_pecl - this PR will add a basic composer.json definition to the skeleton extension

Fixes php/pie#368

[dktapps]

It might be worth thinking about whether to put the vendor name in the generated extension name. Since vendor is going to be present anyway and it'd be better to avoid extension name conflicts in community extensions from different vendors.

Not too sure how this would work or if / can even be put into an extension name though...

[asgrim]

It might be worth thinking about whether to put the vendor name in the generated extension name. Since vendor is going to be present anyway and it'd be better to avoid extension name conflicts in community extensions from different vendors.

That's up to each vendor to select their extension name. Extension names must follow the regex ^[A-Za-z][a-zA-Z0-9_]+$ for backwards compatibility anyway.

[dktapps]

Right, I suppose the backwards compatibility constraint is a bit awkward.

Side note: I've tried the underscore thing before for vendor separation, it's not ideal because the --enable flag becomes a mix of - and _, e.g. --enable-pocketmine_chunkutils. It can be changed after the fact of course, I just wondered whether it might be worth considering this in the generator. If the generator accepted separate vendor & ext names it could generate names more easily.

[asgrim]

ya, I understand the concern, but I think perhaps a little out of scope of this change 😁

[mvorisek]

Is your-vendor a valid vendor name? (can it be accepted by a) composer CLI, b) Packagist, c) PIE) If rejected by all, then it is safe, as user will be always required to change it.

[stof]

The composer CLI and Packagist require the vendor name to match [a-z0-9]([_.-]?[a-z0-9]+)* (per https://github.com/composer/composer/blob/c5b43d328a8cb8f95c3dacae2f232e607ab6a3a6/res/composer-schema.json#L9C26-L9C52). As PIE relies on the composer JSON schema, I think it accepts the same names than composer.
So your-vendor is a valid vendor name (it is actually even already used on packagist.org: https://packagist.org/packages/your-vendor/, which means that other maintainers cannot register new packages under that namespace due to the namespace ownership rules of packagist.org, but the existing maintainer can)

[asgrim]

Indeed, it's a good point, that's why I explicitly changed the vendor name to something invalid:

    "name": "<your-vendor-here>/%EXTNAME%",

This means it will not pass composer validate and cannot be sent to Packagist until this is updated by the author.

[dktapps]

What about requiring the vendor as an arg to the generator?