Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Parser Laravel Package

orchestra/parser

Orchestra Parser is a lightweight PHP package from the Orchestra Platform that turns structured data formats into usable PHP arrays through a simple, extensible API, making it easy to read and transform configuration or markup in Laravel applications.

View on GitHub
Deep Wiki
Context7

XML Document Parser for Laravel and PHP

Frequently asked questions about Parser
What is orchestra/parser used for?
Orchestra Parser provides a single Parser contract with parse() and format() methods for converting structured data formats into PHP arrays. The package context describes support for XML, YAML, INI, JSON, and CSV, backed by Symfony components and a Laravel service provider. It is best suited to build-time or tooling-time transformations such as config ingestion, format conversion, stub or blueprint compilation, and definition-to-class generation. It is not ideal as a general-purpose runtime request-path parser when you only need one known format.
How do I install orchestra/parser in a Laravel application?
Install it with Composer, for example composer require orchestra/parser, and use the version constraint that matches your Laravel major. Laravel package discovery auto-registers the service provider, so you can resolve the parser from the container without manual configuration. After installation, verify the actual Parser contract and supported formats in the installed source before wiring it into application code. If you are on Laravel 11 and not upgrading, do not bump to v10 just for a spelling fix.
Does orchestra/parser parse XML only, or does it support multiple formats?
The package metadata calls it an XML Document Parser, but the broader package description and evaluation describe a unified parse/format API across XML, YAML, INI, JSON, and CSV. Those are materially different scopes, so treat the contract as unverified until you read composer.json and the actual Parser interface in the installed version. Confirm which format adapters ship in your pinned release and whether they are backed by Symfony components. Do not let a design review inherit the assumption that this is a PHP source or AST parser.
Which Laravel and PHP versions does orchestra/parser v10 support?
Version 10.0.0 visibly adds Laravel 12 support and a spelling fix, and majors in this ecosystem typically track Laravel majors. The exact PHP and Laravel constraint ranges are not confirmed in the provided context, so check composer.json for the precise requirements. Older framework majors are presumptively dropped in a major bump. Validate the constraints against your current pin before upgrading.
How do I configure orchestra/parser?
The integration story is intentionally low-friction: Composer install, Laravel package discovery, a service provider, and a container binding, with zero required configuration for basic use. You typically type-hint or resolve the Parser contract from the container rather than instantiating format-specific classes directly. If you need to customize behavior for a specific format, inspect the package's service provider and contract bindings in the installed source. Keep configuration minimal and prefer the underlying format library directly if you need fine-grained parser control.
Is orchestra/parser safe to use on the runtime request path?
It is mechanically simple and container-resolvable, but the evaluation positions it as a narrow utility dependency for build-time or tooling-time transformation, not as a runtime request-path parser. For a single known format on the request path, a format-specific library is usually clearer, cheaper, and easier to reason about. If you do use it at runtime, add caching, golden-file tests, and explicit error handling around parse failures. Confirm the actual format scope first, because the XML-only versus five-format discrepancy changes the risk profile.
How should I test orchestra/parser output in a Laravel application?
Use golden-file or snapshot tests around the parse() and format() outputs, especially where the results feed generated artifacts or configuration. Pin the package version and assert on concrete output shapes so any behavior drift from a major upgrade is caught immediately. Add integration tests that resolve the Parser contract from the Laravel container rather than only testing the underlying Symfony component. Because the package has negligible community usage, your own test suite is the primary safety net.
What are the alternatives to orchestra/parser?
If you only need one format, go direct to the underlying engine or a format-specific library such as a dedicated XML, YAML, JSON, INI, or CSV parser, often the same Symfony component the wrapper uses. Outside Laravel, or where you need fine-grained parser control, the wrapper's main value, container ergonomics and a stable contract, is less compelling. Within Laravel, alternatives include resolving the Symfony component directly through the container or using framework-native helpers for simple config ingestion. Choose based on whether you need a unified multi-format contract or just one well-understood parser.
Is orchestra/parser actively maintained and is it risky to depend on?
The evaluation rates blast radius medium-low but uncertainty medium: release notes are sparse, v10 constraints are unverified, and the package has zero dependents and negligible stars, so there is no community safety net. The mitigating factor is that the package is thin, and failures in generated output can be caught with golden-file tests. Treat major bumps as compatibility releases requiring validation rather than patches. Inventory current usage, pin the version, and check sibling Orchestra or generator packages for v10 compatibility.
Can I use orchestra/parser outside Laravel or in plain PHP?
The package is described as usable from Laravel and PHP, and it is backed by Symfony components, so the underlying parsing capability is not inherently Laravel-only. However, much of the wrapper's durable value is Laravel-specific: package discovery, a service provider, and container binding of the Parser contract. In plain PHP or another framework, you would likely wire it manually or go directly to the Symfony component. Evaluate whether the unified contract is worth the extra dependency outside Laravel.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
robertmarney/lara-hierarchial-collections
simonschaufi/rule-doc-generator
emissaoja/emissaoja
blackbricksoftware/gravityforms-civicrm-form-processor
al-rahabi/fancy-crud
jinas/dhivatar-component
mltstephane/laravel-quality
bernskiold/laravel-talentlms
bernskioldmedia/laravel-form-architect
youbar/easy-crud
c-point-labs/laravel-hostyourai
dbravoan/dbcms-admin-theme-dbcms
dbravoan/dbcms-theme-db-cyber
dbravoan/dbcms-blocks-basic
dbravoan/dbcms-module-content-audit
dbravoan/dbcms-module-ai-assistant
paygate-to/paygate-php
padosoft/askmydocs-connector-base
defstudio/supercharged-carbon
bernskioldmedia/laravel-matomo