Once in a while, re-publish the CSS and JS assets

You should consider replacing Backpack's CSS and JS dependencies every few months. How? This article answers exactly that. But first of...

You should consider replacing Backpack's CSS and JS dependencies every few months. How? This article answers exactly that.

But first of all - WHY? Well... at the time you installed Backpack, it published A LOT of stuff in your public/packages folder. At the time, the CSS and JS files were up-to-date. But months later, there are probably non-breaking updates available for most of them, at the speed JS is moving these days. Some of them are even small security fixes, which you should definitely consider having.

But by default, when you run composer update, Backpack DOES NOT re-publish the public assets. That is because we want you to be in complete control of the assets you have in public (and never overwrite them behind your back). But... if you haven't made changes inside public/packages (as we always recommend you don't), you can easily republish all assets, and even make it an automated process.

Here are 3 ways to do that, each one better than the last. Check it out.

(1) Manually running the publish command

To re-publish all Backpack CSS & JS assets, just this one time, use this command:

php artisan vendor:publish --provider="Backpack\CRUD\BackpackServiceProvider" --tag=public --force

IMPORTANT NOTES:

• Make sure you commit everything else before you do this; git status should be clean;
• This will take everything from vendor/backpack/crud/src/public/package and put it on top of your public/packages. That means it will overwrite EVERYTHING, so only do this if you haven't changed anything in there;
• Before you commit the changes, take a look at them and make sure you haven't lost anything you wrote; a good Git client like Fork will make it easy;
• YES this will overwrite all the files; but NO this won't be add a HUGE amount to your .git folder most of the time, since Git will only record as changes the files that have actually been changed (damn it, Git is smart);
• If you regret doing this git reset --hard HEAD and git clean -f -d are your friend;

THE RESULT:

Now... for most people, doing this once in a while is the safest best. But if want to automate it, or to find a way around republishing assets at all, that's simple too.

(2) Auto-publishing the assets on composer update

If you know that:

• you're never going to touch the public/packages folder; so it'll always be safe to overwrite;
• you don't run composer update too often; so you're not worried about bloating your .git folder too much, by republishing the assets every time;

You can make it so that composer update also republishes the Backpack assets, every time. And it's super-simple. Just add this to your composer.json:

    "scripts": {
        "post-root-package-install": [
            "php -r \"copy('.env.example', '.env');\""
        ],
        "post-create-project-cmd": [
            "php artisan key:generate"
        ],
        "post-install-cmd": [
            "Illuminate\\Foundation\\ComposerScripts::postInstall"
        ],
        "post-update-cmd": [
-            "Illuminate\\Foundation\\ComposerScripts::postUpdate"
+            "Illuminate\\Foundation\\ComposerScripts::postUpdate",
+            "php artisan vendor:publish --provider='Backpack\\CRUD\\BackpackServiceProvider' --tag=public --force"
        ],

THE RESULT:

But you know... there's also another way, which would also take up less space on your server.

(3) Creating an ALIAS to the vendor directory

Think about it - if the assets are stored in vendor/backpack/crud/src/public/packages anyway, and they're just copied to public/packages... we have the assets twice, on the same server. While this can ensure that you're running exactly the assets you want, even if Backpack pushes changes to them, you might not want about this, if you never actually modify the CSS and JS assets. So:

• if you do never modify the assets in public/packages;
• if you never put more things in that folder (caugh... by installing Backpack/FileManager for example... caugh)

Then that means you could also... remove public/packages directory entirely, and just add an alias to the vendor/backpack/crud/src/public/packages directory. That way:

• you're only holding those assets once, in the vendor directory;
• every time you run a composer update you get the newest CSS&JS assets too, because you're just loading them from the vendor folder;

Here's how you can easily do that in Unix:

cd public
rm -r packages
ln -s ../vendor/backpack/crud/src/public/packages

On Windows, you can create a symlink using:

cd public
rmdir /S "packages"
mklink /D packages ..\vendor\backpack\crud\src\public\packages

Of course, you should take into consideration if you local/staging/production environments are different. You might choose to create the alias manually there, not on localhost also.

THE RESULT:

I hope you'll find this helpful.