Search by

proresult / php-typescript-rpc-server

projostein

Server side code used by generated rpc php code, and the server request handler.

Package info

bitbucket.org/proresult/php-typescript-rpc-server

pkg:composer/proresult/php-typescript-rpc-server

Statistics

Installs: 12 947

Dependents: 1

Suggesters: 0

v0.18.0 2026-10-27 11:37 UTC

README

This project contains shared code used in the php-typescript-rpc-codegen and in the code that uses php-typescript-rpc-codegen to build a php server and matching typescript client.

Should be considered beta level. Proresult uses it in production, and don't anticipate backwards breaking changes to happen within 0.x versions.

Created by Proresult AS (https://www.proresult.no)

Requirements

PHP 8.2 or newer within the PHP 8 series is required. Symfony Serializer and PropertyAccess must be version 5.4 or newer within the Symfony 5 series.

Enum properties

Request and response models support string-backed and int-backed enum properties. For example, JSON {"status":"ready","brewStrength":2} is deserialized into the corresponding enum cases declared by the model's property types. Response serialization converts those cases back to their backing values.

Incoming values must match both a declared backing value and its type. Numeric strings and floats are rejected for int-backed enums; null is rejected for non-nullable enum properties. Invalid input results in a BadRequestException.

Pure enums, direct enum method arguments, and direct enum return types are not part of the supported enum-property scope.

Date transport types

  • RpcDateTime represents an instant and is serialized as an RFC 3339 date-time.
  • RpcDate represents a timezone-neutral calendar date. Its wire format is exactly YYYY-MM-DD; timezone normalization is never applied to it.

Use RpcDate for birthdays, workdays, reporting periods, and other values where the calendar date itself is the complete value. Use RpcDateTime for events and timestamps that identify a moment in time.

Deploying new versions

After reviewing and merging the changes into main, users with repository write access can publish a version by tagging the release commit with an appropriate version tag (for example, v0.18.0) and pushing that tag to Bitbucket.

Pushing the version tag is the publication trigger and must be a deliberate manual release action. The test pipeline does not create or push release tags.

The new version should then be available on packagist, so a composer update to the new version in dependent project(s) should work.