Frequently asked
questions

In most cases, no. There are a small number of syntax patterns where Pext cannot convert code directly — named arguments in function calls (PHP 8.0) are one example. For these cases, Pext includes an automated pre-processing step that applies the necessary corrections before transpilation begins, such as rewriting named arguments to their positional equivalents. No manual intervention is required.

There is no upper bound on project size. On the lower end, Pext is best suited to non-trivial projects — the tooling and engagement model is designed for codebases where a full migration effort is warranted.

Pext was designed to cover PHP 5.5 through 8.4. Most of the open source projects in our showcase use PHP 8.x, which represents the primary focus of our testing and validation. That said, no version in that range is intentionally excluded — compatibility coverage across specific versions is still being characterised.

Ideally, no refactoring or restructuring of the codebase is needed before transpiling. Pext converts file by file and faithfully reproduces the original file system structure in the output. Non-PHP resources are copied across automatically.

Dependencies are included in the transpilation — the entire vendor directory is converted to JavaScript alongside your own code. There is no implicit or special-cased vendor handling. Frameworks and libraries such as Laravel, PHPUnit, and Symfony are transpiled as regular PHP code and become part of the JavaScript project output.

They are not. Code that is not written in native PHP — such as C extensions — is outside the scope of transpilation. After conversion, such extensions can be replaced with equivalent Node.js libraries or rewritten for the JavaScript ecosystem. We offer this as part of our consultancy engagement.

Yes — that is the primary goal of Pext: delivering a JavaScript codebase that your team can continue building on. Readability of the output is a core focus, though functional correctness always takes precedence. The Pext team continuously works to simplify the generated code without putting correctness at risk.

Pext includes post-transpilation tooling that performs static analysis on the output — checking for syntax correctness, dead code, redundant code, and similar issues. That said, JavaScript is an interpreted language, and static analysis alone cannot guarantee runtime correctness. The most reliable confirmation is a test suite: any existing PHP tests that can be run against the transpiled output are highly valuable for verifying behavioural equivalence.

The transpiled code relies on the Pext runtime to faithfully reproduce PHP behaviours — including a non-trivial set of quirks and edge cases that are handled transparently by the Pext layer. To run it, use the `pext` CLI: a pre-configured Node.js environment that embeds the Pext runtime and handles all necessary bootstrapping. The goal is for the `pext` CLI to be a complete replacement for the `php` CLI, so you can execute transpiled code exactly as you did in the original project.

No. The goal of Pext is to produce a fully functional JavaScript project — no manual intervention required. If any part of the output needed hand-editing to work correctly, that would indicate a bug in the transpiler, which we would fix on our end. The resulting code is intended to be complete and ready to deploy as-is.

All required third-party dependencies are bundled through the Pext layer — for example, libxml bindings for XML processing. You do not need to source or configure them separately. Pext takes responsibility for the safety and curation of every third-party package used in the converted output.

Constructs with no direct JavaScript equivalent are routed through the Pext runtime, which provides the necessary implementations. For example, pass-by-reference is handled within the runtime: variables are wrapped in a Pext-specific type that carries the reference semantics PHP developers expect. Similarly, PHP arrays are reimplemented as a custom Pext type that replicates their full behaviour — ordered iteration, associative keys, automatic integer key generation, internal cursor, and so on. Where appropriate, vanilla JavaScript constructs are used directly to mirror the original PHP behaviour. The goal is that these constructs behave identically to their PHP counterparts without requiring any changes to the converted code.

Performance is important to the Pext team, but functional correctness always comes first. Pext is oriented towards full PHP compatibility under reasonable performance standards, and strives to be on par with PHP in most cases. That said, some PHP patterns may not map perfectly to the JavaScript execution model — JIT compilation behaviour is one example where differences can emerge. Because the converted code is entirely yours, you have the freedom to identify and optimise hot spots using vanilla JavaScript, while leaving the bulk of non-critical code untouched.

There is a well-defined scope for what can be carried over from PHP in terms of dynamic code execution. Pext will not run any PHP code at transpile time or at runtime — the output is JavaScript only. If the transpiled code generates PHP code dynamically, executing it must go through eval, which will convert it to JavaScript on the spot with certain limitations. I/O operations that reference .php file extensions — such as checking for file existence — are supported with limitations. The Pext runtime can be configured to resolve these automatically by rewriting .php paths to .js equivalents on the fly.

Currently, Pext provides a CLI equivalent to the PHP CLI. If the original application was served by Apache or NGINX using mod_php, routing those requests through the Pext CLI in place of the PHP CLI will yield the same result. Pext plans to expand on deployment in future, with more canonical deployment paths. In the meantime, how the resulting JavaScript code is deployed is your decision — the output is standard Node.js and can be run in any environment that supports it.

The Pext runtime currently targets Node.js 22. The generated code is intentionally vanilla — it runs natively on the V8 engine without requiring an additional build step, transpilation tool (such as Babel), or experimental feature flags. The output is self-contained and ready to run as-is.

No. Pext converts code file by file — each PHP file is transpiled to its JavaScript equivalent independently, without requiring knowledge of the rest of the project. This means you can convert incrementally and ship files at your own pace.

Pricing is determined on a per-customer basis, depending on the services required — conversion, consultancy, maintenance, or a combination. Book a demo to discuss your needs and work out the right next steps.

The transpiler (pextc) is closed-source and proprietary — it is the core mechanism behind the PHP-to-JavaScript conversion. Its binaries are not distributed. The Pext team runs the transpiler in-house and delivers the converted output directly to you.

Any transpilation engagement is conducted under a prior agreement that establishes the appropriate disclosure boundaries. Our team is experienced with enterprise codebases and operates with the confidentiality standards that entails. The tooling runs entirely offline — your code is never transmitted to external services.

The Pext runtime is distributed as binaries on a per-module basis — covering areas such as arrays, DOM, JSON, and so on. During the transpilation engagement, you are licensed to use the runtime for testing the converted application. Once the engagement concludes, you receive a perpetual licence to run the runtime in the context of your converted project. This licence also extends to new JavaScript code developed within the same company using the Pext runtime. It does not cover redistribution or resale of the runtime to third parties.

The converted code belongs to the owner of the original PHP codebase, as established in the agreement made prior to the engagement. Pext makes no claim over the business logic of the converted output. The licensing of the final JavaScript code, and the extent to which the Pext team may continue processing the shared source, is entirely at the discretion of the codebase owner.

At the close of a transpilation engagement, the owner receives a runtime licence for the latest major version available at that time. Under a maintenance agreement, this includes regular updates — minor versions — for a defined support window within that major version. Extended maintenance beyond the standard support period is available through a separate agreement. Upgrading to a new major version is not covered by the standard support obligations: major runtime versions correspond to specific conversion generations, and migrating to a new major requires adapting the converted code to the updated runtime. Code migration assistance for major version upgrades is not included implicitly — Pext offers consultancy services for this.