Freek.dev

Sebastian De Deyne, my colleague and all round wizard at Spatie, wrote a new blogpost on how we use Babel.

A lot has been going in in JavaScript the past few years. One of my favorite things has been the usage of babel, which allows us to write future JavaScript syntax today. The babel ecosystem has tons of plugins and configuration options, I'd like to elaborate on our usage at Spatie.

https://sebastiandedeyne.com/posts/2017/whats-in-our-babelrc

Read more

Testing @spatie_be 's media library with the new #laravel upload fakes ? Trust, but verify ? #testing pic.twitter.com/Ss98rGloRf

— Christoph Rumpel (@christophrumpel) July 3, 2017

Read more [twitter.com]

Tinker is probably one of my most used Artisan commands. A minor annoyance is that it can be quite bothersome having to type the fully qualified classname to do something simple.

Today we release a new package called laravel-tinker-tools. When fully installed let's you use the short class names in a tinker session:

This magic does not only work with models but with every class in your Laravel app.

Installing the package

There are a few non standard steps you need to take in order to install the package.

First, pull in the package like you normally would:

composer require spatie/laravel-tinker-tools

Next, create a file named .psysh.php in the root of your Laravel app with this content:

<?php

\Spatie\TinkerTools\ShortClassNames::register();

Finally, dump the optimized version of the autoloader so autoload_classmap.php gets created.

composer dump-autoload -o

And with that all out of the way you can use short class names in your tinker session.

A peek behind the curtains

When you use a class that hasn't been loaded in yet, PHP will call the registered autoloader functions. Such autoloader functions are responsible for loading up the requested class. In a typical project Composer will register an autoloader function that can include the file where the class is stored in.

Composer has a few ways to locate the right files. In most cases it will convert the fully qualified class name to a path. For example, when using a class App\Models\NewsItem Composer will load the file in app/Models/NewsItem.php. It's a bit more complicated behind the scenes but that's the gist of it. To make the process of finding a class fast, Composer caches all the fully qualified classnames and their paths in the generated autoload_classmap.php, which can be found in vendor/composer.

Now, to make this package work, \Spatie\TinkerTools\ShortClassNames will read Composer's autoload_classmap.php and convert the fully qualified class names to short class names. The result is a collection that's being kept in the $classes property

Our class will also register an autoloader. When you use NewsItem in your code. PHP will first call Composer's autoloader. But of course that autoloader can't find the class. So the autoloader from this package comes next. Our autoloader will use the aforementioned $classes collection to find to fully qualified class name. It will then use class_alias to alias NewsItem to App\Models\NewsItem.

What happens if there are multiple classes with same name?

Now you might wonder what'll happen it there are more classes with the same name in different namespaces? E.g. App\Models\NewsItem, Vendor\PackageName\NewsItem. Well, autoload_classmap.php is sorted alphabetically on the fully qualified namespace. So App\Models\NewsItem will be used and not Vendor\PackageName\NewsItem.

Because App starts with an "A" there's a high chance that, in case of a collision, a class inside your application will get picked. Currently there are no ways to alter this. I'd accept PRs that make this behaviour customizable.

Need more tinker magic?

There are a lot of other options that can be set in tinker.config.php. Learn all the options by reading the official psysh configuration documentation. Caleb Porzio's excellent blogpost "Supercharge Your Laravel Tinker Workflow" is an excellent read as well. This package was inspired by that blogpost

Maybe you don't need tinker...

If you want to run a single line of code tinker can be a bit of overkill. You must start up tinker, type the code, press enter, and quit tinker. Our laravel-artisan-dd package contains an Artisan command that can dump anything from the commandline. No need to start and quit tinker anymore.

We've updated the package so you can make use of short class names too. Here's how you can dump a model using a minimal amount of keystrokes:

In closing

laravel-tinker-tools and laravel-artisan-dd aren't the only packages we've made that make developing Laravel apps easier.

Be sure to take a look at these ones at well:

• laravel-tail
• laravel-migrate-fresh
• laravel-db-snapshots
• laravel-mailable-test
• laravel-demo-mode

Need even more stuff? The open source section on our company website lists everything we've released previously: https://spatie.be/en/opensource

Read more

If you want to know how a visitor got on your site you can check the referer request header. Yeah, it's misspelled. That header contains the url of the previously visited page. Unfortunately browsers will fill that header regardless of the previous url was an internal or external one. So after the first click on an internal link you won't know anymore on which site a visitor was on previously.

Our new laravel-referer package aims to fix that problem. Once the package is installed it will remember the original referer in session. So even after a users clicks around on your site, you are still able to detect which site he or she visited previously.

Because users are also often tracked using UTM Codes the package will also remember the utm_source query parameter.

The easiest way to retrieve the referer is by just resolving it out of the container:

use App\Spatie\Referer\Referer;

$referer = app(Referer::class)->get(); // 'google.com'

Or you could opt to use Laravel's 5.4 fancy new automatic facades:

use Facades\Spatie\Referer\Referer;

$referer = Referer::get(); // 'google.com'

To know more take a look at the readme of the package on GitHub.

https://github.com/spatie/laravel-referer

Read more

Jordi Boggiano and Nils Adermann, creators of Composer, have recently released a paid version of Packagist. The service aims to make managing private packages a breeze.

Private Packagist aims to remove all these hurdles for businesses to finally make working with Composer as convenient as it should be. Being a hosted service, setting up your own Composer package repository on Private Packagist is done with a few clicks. No matter if your private source code is hosted on GitHub, GitLab, Bitbucket, any of their on-premise solutions, or in any other Git, Mercurial, or Subversion repository, Private Packagist can immediately access your code after setting up your credentials to make it available for installation through Composer.

https://medium.com/packagist/introducing-private-packagist-492553d10660

If you're not afraid to get your hands dirty you could, instead of using Private Packagist, choose to use Satis. This tool is also written by Jordi & Nils. Laravelista has posted this great tutorial to get you started with the tool.

At Spatie we have set up a satis server to register packages that are intended to only be used in our own projects.

Read more