Remove CSS & JS from Composer package

[tabacitu]

In short, Backpack 4 has a weight problem... it's gotten to be almost 100MB. But most of that weight is carried inside... the public/packages directory:

This makes (CONs):

• the package a little slow to download and install (composer install, but also composer update even though those new assets won't be published)
• the whole project take up more space than needed (those 96MB are stored both inside vendor/.. and inside public/..;
• be judged as a JS project by Github (which doesn't really matter, but it's annoying to me personally)

But the fact that we have the assets there (PROs):

• saves the dev from having to run NPM when installing Backpack;

The trick is... how do we solve the CONs, without eliminating the PROs?

---

What if... we used export-ignore in .gitattributes to prevent public/packages from being included in the ZIP that Composer downloads? Then:

• backpack/crud, when installed/updated with Composer, would be just ~4MB;
• we need to figure out a way to download those assets and put them in public/packages some other way; so what we need is a php artisan backpack:publish-assets command, that will do just that;

That command could:

• (a) download a zip with just the assets for that particular version, and unzip it;
• (b) use NPM to run the Laravel Mix script from vendor/backpack/crud, if the use is ok with using NPM;

That zip could live inside backpack/crud (auto-built for each version, also in export-ignore of course) or it could be in a mirror repo, that only has those files, not everything else in Backpack (or have everything but the exact reverse - everything else would be in export-ignore).

---

This is either a very good idea. Or a very stupid one. Not sure which one it is yet - eager to see if anybody has thoughts on this either way 😀 I just wanted to get it off my chest.

Might also be not needed at all if we decide to use CDNs again (with auto-localized assets).

Food for thought.

[tabacitu]

Ok so it's confirmed by Laravel-Backpack/CRUD#4008. Add src/public/ to .gitattributes and it won't be in the ZIP file, composer install and composer update won't have it.

But then... how do we get the CSS & JS assets, upon installation? We need a php artisan backpack:publish-assets command, but HOW will that command download the CSS & JS assets and copy them to public/packages?

Option 1) git clone

We clone Backpack from source. This worked for me:

git clone https://github.com/Laravel-Backpack/CRUD.git public/temp/backpack
cd public/temp/backpack
cp -R src/public/packages ../../packages
cd ../../..
rm -r public/temp/backpack

The problem here is... you have to know EXACTLY what branch/tag/release to get. But I guess we can get that using

• \PackageVersions\Versions::getVersion('backpack/crud') in Composer v1, which will return 4.1.61@4400187391eb5b73672c2b166a990cd737277409; we can then use either the hash after @ to checkout to the proper release;
• \Composer\InstalledVersions::getVersion('backpack/crud') in Composer v2, which will return 4.1.61.0; we can strip out the last zero and checkout to 4.1.61;

So this is doable, but...

• it's not exactly a cool thing to do;
• it requires the dev to have git installed and aliased... which they might not; I've seen that happening, it's real;
• it will need need to work both on UNIX & Windows, and I can see this breaking for some people, for some reason;

Option 2) curl or wget to Github

We can do something like curl -L -o master.zip http://github.com/laravel-backpack/crud/archive/test-gitattributes-export-ignore.zip which will get the ZIP from Github... but that ZIP will NOT have the src/public/ directory. It's a 0.9MB file, not the big 40.3 MB one. So this won't work.

Option 3) Move CSS & JS assets to a different repo

That could be either @digitallyhappy/backstrap or a different one. It would be a JS package, not a PHP one, with the current package.json, Laravel Mix and everything. But it would probably be difficult to keep assets up-to-date, in both the PHP package and the JS package. When you bump the version in one you have to bump the version in the other. Bleah, difficult to maintain.

Option 4)svn

Profit on the fact that Github has svn support, and download the src/public/packages directory using that:

svn export http://github.com/laravel-backpack/crud/trunk/src/public/packages backpack-public-packages

But that would require the dev to have svn installed. Which is even worse than asking them to have npm installed. So no, this is definitely not a good option.

Option 5) download-directory

Use a third-party like this to download the src/public/packages directory to the right spot. But this did not work for me, for the entire directory (it's probably too big):

# doesn't work (it's probably too big)
https://download-directory.github.io/?url=https://github.com/Laravel-Backpack/CRUD/tree/test-gitattributes-export-ignore/src/public/packages

# subsets of that directory DO work, for example you CAN do
https://download-directory.github.io/?url=https://github.com/Laravel-Backpack/CRUD/tree/test-gitattributes-export-ignore/src/public/packages

Note: its alternatives GitZip and DownGit did not work for Backpack either.

Option 6) curl to an assets.backpackforlaravel.com endpoint

We could do exactly what download-directory does, but only for our project, our releases, our tags, from our domain (eg. assets.backpackforlaravel.com. It would be safer, because we control it, and it would do exactly what we want. We'd basically create a bunch of zips, automatically, for every version we release:

• https://assets.backpackforlaravel.com/backpack/crud/4.1.61.zip
• https://assets.backpackforlaravel.com/backpack/crud/4.1.62.zip
• https://assets.backpackforlaravel.com/backpack/crud/4.1.63.zip
• https://assets.backpackforlaravel.com/backpack/crud/4.2.0.zip
• etc.

Then the php artisan backpack:publish-assets would download it, unzip it and replace the contents of public/packages (the same thing as Laravel's --force when publishing). The server load wouldn't be a problem either, because we can cache those automatically using CloudFlare. And they'll probably be available even if our site is down.

This still has the downside of needing zip to be installed, but I guess for people who don't have it we can have a manual procedure - give them a link and tell them to unzip it to the right directory, easy-peasy.

Option 7) Move back to using assets from CDNs

Instead of providing those JS files inside Backpack, we could just point to the CDN files. If we have something like DigitallyHappy/assets#2 then the files could be easily downloaded, either as-needed or using a command.

To reduce counter-party risk, we could keep the files in our Github repo, like they are now. We don't point to the DataTables CDN, we point to https://cdn.jsdelivr.net/gh/laravel-backpack/crud@4.1.61/src/public/packages/datatables.net-bs4/js/dataTables.bootstrap4.min.js which will take the file from our own Github repo.

---

Food for thought.

[lakuapik]

i love the idea from option 7, i think its the best idea, user still have an option to use cdn or download the packages folder. also will this be released on version 4 or only for the next major release?

by the way, my current solution (by not wasting some space) is this:

• https://github.com/Laravel-Backpack/CRUD/discussions/3778

[tabacitu]

Update: we've had a breakthrough here. @promatik has already implemented Option no 7, it's 80% done and it works LIKE FREAKING MAGIC:

• Added bassets feature DigitallyHappy/assets#14
• [6.x][WIP] Bassets 🐶 CRUD#4815
• https://github.com/Laravel-Backpack/PRO/pull/110
• [6.x] Bassets demo#449 <---- has installation instructions

We still have a few quirks to work out. But this is very VERY promising.

[lakuapik]

@tabacitu @promatik wow thats awesomee!! 🎉🎉

[tabacitu]

We have too many issues open for this, so close this and continue the conversation in Laravel-Backpack/CRUD#4815