You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed the package currently expects APP_KEY to be present in the values returned from Infisical. In practice, APP_KEY is typically generated locally after a clean install via php artisan key:generate, and requiring it to be stored/shared in Infisical adds friction (and pushes users toward sharing a the same app key between the environments which is -imo- unnecessary).
Because of that, I don’t think APP_KEY should be treated as required by the Infisical export/merge flow. A more ergonomic default would be to ignore APP_KEY if it’s missing (or at least not fail the command), while still allowing teams to manage it in Infisical if they explicitly want to.
I’m happy to open a PR for this change if you’re open to it. If not, I can fork and maintain the adjustment on my side.
I noticed the package currently expects APP_KEY to be present in the values returned from Infisical. In practice, APP_KEY is typically generated locally after a clean install via php artisan key:generate, and requiring it to be stored/shared in Infisical adds friction (and pushes users toward sharing a the same app key between the environments which is -imo- unnecessary).
Because of that, I don’t think APP_KEY should be treated as required by the Infisical export/merge flow. A more ergonomic default would be to ignore APP_KEY if it’s missing (or at least not fail the command), while still allowing teams to manage it in Infisical if they explicitly want to.
I’m happy to open a PR for this change if you’re open to it. If not, I can fork and maintain the adjustment on my side.