Neon Laravel Package

Product Decisions This Supports

• Configuration-format strategy: Evaluate whether NEON belongs in a Laravel product at all. This package supports a deliberate decision to use NEON for human-edited configuration, fixtures, or internal tooling — not as a default replacement for Laravel’s PHP/JSON/YAML config stack.
• Build vs. buy for NEON parsing: Strong “buy” if NEON is a real requirement. The package provides a maintained encoder/decoder, AST parser, linter, atomic decodeFile(), UTF-8 handling, and PHP 8.4/8.5/8.6 support. Building equivalent parsing, linting, and edge-case handling would be expensive and low-differentiation.
• Nette interoperability / migration: Enables product decisions around onboarding Nette-based services, importing existing NEON configs, or supporting hybrid stacks during migrations. This is the clearest product use case.
• Developer tooling and CI quality: The bundled linter and strict parsing support roadmap items like config validation in CI, consistent formatting, and safer review of nested configuration changes.
• Internal CLI and test-data configuration: Useful where readability of nested data matters more than runtime interchange with external systems — e.g., internal tools, seed fixtures, or complex local config.
• Data-fidelity expectations for imported configs: Since v3.4.9, date-shaped literals that are not valid dates (e.g. 2024-02-30, 2024-13-01) decode as plain strings instead of erroring. If a product imports third-party NEON, decide explicitly whether malformed dates should be silently tolerated as strings or rejected in validation — this affects import UX and downstream date parsing.
• Risk and roadmap scoping: The package’s minor-version BC breaks (e.g. v3.4.0 PHP 8 requirement and syntax removals; v3.3.0 parser rewrite; v3.4.9 reserving the !!chain entity name), plus NOASSERTION licensing, are product risks to price into any roadmap that depends on NEON.

When to Consider This Package

• Adopt if NEON is already an organizational or integration requirement, especially when migrating from Nette or interoperating with Nette-based services.
• Adopt if the use case is bounded: internal tooling, CLI configs, test fixtures, or a clearly scoped NEON import/export path. In these cases the package’s readability, comments, multiline strings, and linter add real developer value.
• Adopt if your team is on PHP 8.0+ and values static-analysis-friendly APIs. The v3.4.8 phpDoc improvements reduce IDE friction and v3.4.9 adds PHP 8.6 support, but neither creates Laravel integration.
• Adopt with legal review because the license is marked NOASSERTION in the provided metadata despite common assumptions about Nette’s licensing. Do not ship it into a commercial product without clarifying terms.
• Watch for minor-version BC drift: v3.4.9 reserves !!chain for chained entities (no longer writable in input) and changes decoding of invalid date-shaped literals to plain strings. Neither is a major-version bump, so pin versions and test NEON fixtures on upgrade if your inputs contain !!chain or date-like values.
• Look elsewhere if the goal is “better Laravel config.” Laravel is not NEON-native: there is no built-in config loader, no config:cache integration, and no service-container integration. PHP arrays, JSON, or YAML are simpler and better supported.
• Look elsewhere if you need broad ecosystem adoption signals. Stars are healthy, but the package is Nette-centric and the dataset shows 0 dependents; it is not a mainstream Laravel dependency.
• Look elsewhere if you cannot tolerate BC risk or maintain a custom adapter. Supporting NEON in Laravel requires custom bootstrapping, cache strategy, and ongoing ownership.

How to Pitch It (Stakeholders)

For executives: “NEON is not a Laravel-native config format, so this is a scoped interoperability and tooling decision, not a platform rewrite. The package is mature and actively maintained — v3.4.9 adds PHP 8.6 support and tightens parsing edge cases — but it carries licensing ambiguity and minor-version BC risk. I recommend adopting it only where NEON is already required — Nette migrations, internal tooling, or config import/export — with legal review and a named owner for the Laravel adapter.”

For engineering: “Use nette/neon as a focused encoder/decoder and linter, not as a replacement for Laravel’s config system. It gives us a maintained AST parser, atomic file reads, UTF-8 handling, multiline strings, and PHP 8.6 support. v3.4.9 also makes invalid date-shaped literals decode as strings and reserves the !!chain entity name, so pin the version and re-run NEON fixture tests on upgrade. The cost is integration: we must build and own any Laravel config loader or cache path, and we must test against BC-sensitive releases. Best fit: Nette interop, fixtures, CLI configs, and CI linting.”

For developers: “NEON is more readable than JSON for deeply nested config and supports comments and multiline strings. The package includes a linter and decodeFile(), recent releases improve phpDoc types for IDE/static-analysis support, and v3.4.9 runs on PHP 8.6. Note two behavior changes in that release: things like 2024-02-30 now decode as plain strings rather than failing, and !!chain is reserved so you can’t write it in input. But this is not a drop-in Laravel config format — use it only for scoped cases where the readability or Nette compatibility benefit is concrete.”