We should not be opening a new page on the links for items that are not supported in the UI. I believe this was leftover from when we redirected to the EasyPost website. Remove the target=_blank from these items.

Currently there is no way to create a return label via the UI. This could either be accomplished by adding a return checkbox which would require the user to add all the information again or we could start storing records in the DB. Neither are great as the DB was only intended (at least initially) to house login details and the EasyPost API Key, the other isn't great for the user.

There are various new versions of the lib we should use here, performance gains and thread-safety plus new features are a big reason to upgrade.

It appears that all of the buttons that should be returning a page are instead returning it via POST so the page loads but the URL is messed up because of it and if you try and take an action from that page, it breaks due to it trying to re-hit the URL loaded which is the previous POST url (eg: create a shipment, then attempt to buy a label, it will break thinking you tried to hit the create-shipment route again.)

Introduce GET pages that these post forms can land you on safely

Currently the level of validation is a bit aggressive. EasyPost will spit back errors when they can't build records, a lot of the validation should fall on them instead. For instance, the state field is required on addresses via this UI but isn't always required (international addresses) via EasyPost.

Currently the app is intended to only be deployed locally. I've already added the Laravel auth scaffolding, it should be pretty simple to toss in a database via Docker and allow users to store their API Keys allowing for multiple users.

Currently the UI doesn't allow for anything other than US domestic shipments. Add the ability to add customs info and items.

Currently you can only use the PHP Artisan command and not the docker commands to deploy.

The routing is broken when buying/refunding a shipment. You can get to the rates screen but it breaks when you attempt to buy because the url is still create-shipment on the rates view. It's mixing GET and POST content so it tries to submit create-shipment again when buying when really it needs to be buy-shipment.

Currently Travis only tests if dependencies can be installed and the Dockerfile can be built but doesn't do much PHP testing. We'll need to add that in.

Now that we have a couple simple unit tests, we need to move the API Key from the xml file to an env variable (rather, we need to pass the variable into the unit tests properly.) Once this is done, we can add unit testing to Travis and build out the remainder of the tests.

There are a bunch of NPM packages that need a bump due to security vulnerabilities.

npm audit fix should do the trick.