Smart Export Bundle Laravel Package

Getting Started

This is an early alpha (v0.1.01) whose release notes are a todo list, not a changelog. There is no installation documentation, usage documentation, demo package, or test suite yet. Treat the package as source-first: you will learn it by reading code, not docs.

Minimal steps to get moving:

1. Require it explicitly at the alpha version so Composer does not drift:

   composer require <vendor>/<package>:0.1.01
   

2. Locate and read, in this order:
   • the package composer.json (autoload namespaces, Laravel version constraints, whether it ships migrations/config/assets),
   • the service provider (what it binds, publishes, and registers),
   • the config file (table name, engine options),
   • the Engine class and condition classes (the core behavior),
   • any database/migrations or stubs.
3. Publish whatever the provider exposes, typically:

   php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider"
   

   Check for separate tags for config, migrations, and assets.
4. Set the table name in config/<package>.php before running migrations, then migrate.
5. Build the smallest possible engine with one condition and evaluate it in php artisan tinker. That is your first use case and your de facto documentation.

Because there is no demo, your first integration should be a throwaway test route or command, not application code.

Implementation Patterns

Config-first setup. The planned "Config with table name" feature implies the table is configurable rather than hardcoded. Read the migration stub to confirm whether it reads config('package.table') or a hardcoded name. If it is hardcoded, publish and edit the migration before running it.

Engine + Conditions composition. The release notes reference "Conditions on Engine", suggesting an engine holds a set of conditions that are evaluated together. Until docs exist, map the API from the source:

• How conditions are registered (array, fluent builder, database rows, or class names).
• What a condition receives (model, payload, context array) and returns (bool, result object, or throws).
• Whether the engine short-circuits on the first failed condition or evaluates all of them.

Prefer registering conditions through the container so you can swap or mock them in tests:

$this->app->bind(SomeCondition::class, fn () => new SomeCondition(/* deps */));

Asset integration. "Assets integration" is listed as planned, not delivered. If asset publishing exists, publish to public/vendor/<package> and wire it into your layout. If it expects Vite/Mix, check for a build step in the package; do not assume published assets are precompiled.

Workflow pattern for day-to-day use.

1. Define conditions as small, single-purpose classes.
2. Assemble them into an engine configured from config/<package>.php.
3. Evaluate inside a transaction if condition evaluation can persist state.
4. Log the engine input and the matched/failed condition for auditability.

Integration tips.

• Bind the engine as a singleton only if it is stateless; otherwise resolve per request to avoid condition leakage between evaluations.
• If a facade is shipped, verify it resolves the same binding you configured.
• Wrap engine calls behind your own service class. Given the alpha status, this isolates you from API changes in 0.2.x.

Gotchas and Tips

• No tests, no docs, no demo. This is the dominant risk. Pin 0.1.01 exactly, read the source before adopting, and write your own characterization tests around Engine and each condition type. Do not assume semantic versioning protects you.
• Release notes are aspirational. "Conditions on Engine", "Config with table name", and "assets integration" are listed under Todo, so they may be absent or partially implemented. Verify each in code rather than trusting the notes.
• Table name ordering. Changing the table name after migrating leaves orphaned tables. Set config, clear cached config (php artisan config:clear), then migrate. If you use config:cache in deployment, the table name is frozen at cache time.
• Migration stubs. Published migrations may hardcode the table. Always inspect the published copy, not just the package original.
• Condition evaluation ambiguity. Check for short-circuit behavior, exception handling, and whether a failing condition aborts or is collected. Undefined behavior here is the most likely source of production surprises.
• Asset publishing collisions. If the package publishes to a generic path, confirm it does not overwrite your app assets. Publish tags individually rather than running a blanket vendor:publish.
• Debugging. Use php artisan tinker to instantiate the engine and evaluate a single condition in isolation. Add temporary logging around condition resolution; there is no documented debug mode.
• Extension points to watch. Custom condition classes, engine drivers, and the config file are the likely seams. Prefer extending via config and your own condition classes over subclassing internals, which are most likely to change before 1.0.
• Upgrade posture. With a todo list this large, expect breaking changes in every minor release until the documented features land. Re-run your characterization tests on every bump and diff the service provider and config file first.