Aceeditor Bundle Laravel Package

Getting Started

Read this first: this is a Symfony bundle, not a Laravel package. norberttech/aceeditor-bundle ships a Symfony bundle class, a Symfony form type, a Twig extension, and Twig templates. There is no ServiceProvider, no config/*.php publish tag, no Blade directives, and no entry in Laravel's package discovery manifest. Composer will install it into a Laravel app, but nothing will register itself.

Practical steps if you are evaluating 5.0.0:

1. composer require norberttech/aceeditor-bundle:^5.0 in a scratch Symfony 6.4 app first, not in your Laravel app. Confirm it installs and boots before you spend time on integration.
2. Look at src/AceEditorBundle.php (note the new AceEditorBundle\AceEditorBundle namespace in 5.0.0), src/DependencyInjection/Configuration.php for the config tree, src/Form/Type/AceEditorType.php for the actual form options, and src/Resources/views/ for the templates.
3. Install assets (php bin/console assets:install --symlink) and render one AceEditorType field in a Symfony form. That is the first use case: a code-editor textarea inside a form, wired to a textarea fallback when JS is unavailable.
4. If you are genuinely on Laravel, treat this package as a reference implementation, not a dependency. The parts worth copying are the form-type option schema (mode, theme, height, read-only, auto-height) and the JS bootstrapping. Implement the editor with ace-builds via Vite plus a Blade component, and you get the same result with zero framework impedance.

Where the bundle stops being useful to you: the moment you need a Laravel service provider, a publishable config file, or a Blade include. Nobody has built that bridge in this repo, and 5.0.0 does not add one.

Implementation Patterns

Symfony-side usage (what the package actually supports):

• Register the bundle in config/bundles.php, import the bundle's routing/asset config, then set global defaults once in config/packages/ace_editor.yaml (roughly ace_editor: { options: { ... } } — verify exact keys against Configuration.php, the tree is small and readable).
• Use AceEditorType per field, overriding only what differs from the global defaults. Keep theme/mode/height in config and out of controllers so a design change is one file.
• Template overrides: copy from src/Resources/views/ into templates/bundles/AceEditorBundle/ so you survive upstream template changes. Note the template namespace was corrected in 5.0.0, so overrides written against 4.x may no longer resolve.
• Treat the form type as the boundary. Anything you need beyond its options (autocomplete toggles, custom keybindings, worker URLs) belongs in a small JS initializer keyed off the rendered textarea's data- attributes, not in a fork of the bundle.

Laravel-side patterns that map cleanly:

• Blade component + Vite. One <x-code-editor> component that renders a textarea and hydrates it with ace-builds. Config in config/editor.php with the same option shape as the bundle's config tree, so the mental model transfers.
• Form request + cast. The editor is just a textarea; validation, sanitization, and persistence are ordinary Laravel work. Do not let the editor leak into your domain layer.
• Livewire/Alpine. If you use Livewire, initialize Ace in init() and sync back with wire:model on the hidden textarea. wire:ignore the editor container so Livewire does not clobber the DOM on re-render.
• Progressive enhancement. Always render a working textarea first, then upgrade. This gives you a graceful failure path and makes the feature testable without a browser.
• If you must bridge. Write a tiny AceEditorServiceProvider in your own app that binds the bundle's form type and registers the Twig extension with Laravel's Twig bridge. This is a supported path only if you already run Twig in Laravel; otherwise the cost outweighs it.

Gotchas and Tips

• The 5.0.0 namespace rename is the breaking change. Everything moved to AceEditorBundle\AceEditorBundle. Any use NorbertTech\AceEditorBundle\... in your code, services.yaml, template paths, or form theme references must be updated. Grep for the old namespace before upgrading; this will bite silently as "class not found" at runtime rather than at build time.
• PHP minimum version was raised in the same release (PR #67, alongside deprecation fixes). Check composer.json's require.php against your production and CI runtimes before bumping. If you support an older PHP in a monorepo, this blocks the upgrade for the whole repo.
• preg_match on non-string values in the form type was fixed (PR #68). Previously, passing null or an integer where a string option was expected could error or behave inconsistently. Post-5.0.0 those values are handled — meaning if you had defensive casts or workarounds in your form options, they are now redundant and may mask a real type error. Remove them and let the type system catch mistakes.
• Twig 3 spaceless fix (PR #36) and the template namespace fix (PR #83) mean the rendered markup changed. If you have CSS or JS selectors targeting the bundle's generated DOM, re-verify in a browser. This is exactly the kind of thing that passes PHPUnit and breaks your layout.
• No Laravel integration, and 5.0.0 does not move toward one. Static analysis (psalm/phpstan, PR #82) and dependabot were added, which is a good maintenance signal, but the CI matrix is Symfony/PHPUnit only. Do not read "modernized" as "framework-agnostic."
• Debugging in Symfony: debug:config ace_editor to confirm your config tree actually merged, debug:container for the form type registration, and check the browser network tab for Ace's worker files — the most common failure is a 404 on ace/mode/*.js from an incorrect asset path.
• Watch the dependency bumps. 5.0.0 moved twig/twig to 3.4.3 and Symfony to 6.4.x. If your app pins Twig 2.x or an older Symfony, you cannot take 5.0.0 at all. That is a hard constraint, not a soft one.
• Extension points are thin by design. The bundle is a form type plus a template. If your assessment concludes you need anything more (a Laravel service provider, asset publishing, a config facade), you are writing that yourself — budget for it explicitly rather than assuming an upgrade path exists.