search

Laravel-Backpack / basset

Better asset helpers for Laravel apps.
MIT License
163 stars 11 forks source link

How to create ALL files when needed a manual deploy? #103

Open realtebo opened 1 year ago

realtebo commented 1 year ago

Locally i set 

BASSET_DEV_MODE=false
BASSET_VERIFY_SSL_CERTIFICATE=false

I execute basset:install

It creates this

image

But when I launch the first time the page, It add 2 more files

The 2 added files are added from config/backpack/theme-tabler.php

image

My question is: how can I force basset to internalize and store ALL but really ALL the needed files ?!?!

image

I cannot remember for ALWAYS reload website localy before deploy.

realtebo commented 1 year ago

Could be related to https://github.com/Laravel-Backpack/basset/issues/61 ?

hagealex commented 1 year ago

I might also need this. As mentioned in #104 I manually move the basset files from the storage folder into public. Therefor I need all files to be there at this moment. Files that are generated afterwards won't be accessible.

pxpm commented 1 year ago

Indeed @realtebo it's the same issue.

We are aware of it, I just had a meeting with @promatik yesterday to talk about this pending basset issues. As you can imagine they are the tricky ones, that are left to solve.

to give you an overview of what's the issue, basset is like a "scrapper". It checks your php files for @basset directives and cache the result of those assets.

Some assets are built "on the fly".

To give you a different example, datepicker and most of the select2 fields have a language .js file that is loaded depending on "run-time" values, in this case the app locale. So if the locale is fr it will load some-file.fr.js, if pt would load some-file.pt.js.

Those kind of files are the ones that you say "are created the first time they are encountered". So the first fr visitor would load the some-file.fr.js from the cdn, all the other visits from fr visitor would pick the cached file. When the first pt visitor comes in, we will cache the pt alongside the fr and the cycle repeats for any language your visitors may be using.

There are other examples of such cases, but the reason behind it is because they all depend on run-time values.

We are exploring possibilities of expanding the scrapping abilities or as a last resort if that can't be reliably achieved, we would probably cache ALL the available language files on the first basset:cache so any of them would be available in the cache.

I think this will be a "non-issue" for you when you implement the solution I gave you on the other thread you posted, since those files will be created just as "any other public file" and just works.

Let me know what you think.

Cheers

Antonin-netalis commented 9 months ago

Hey, thanks for the detailed explanation. It seems like a tough problem to solve.

Just thought I'd let you know that I'd also be really interested if there were a way to do this. Our codebase and assets are on entirely different VMs and we use rsync post-deployment to copy storage/app/public/basset to our nginx VM, but files that are created "on-the-fly" are not present at the moment we rsync, have to do a bit of manual action to load those files once after each deployment and rsync again.

If anyone has an idea how to make basset work flawlessly in this kind of setup, I'm interested.

promatik commented 8 months ago

@pxpm what if we did some kind of tag or attribute? (Exactly like the PHP attributes)

'scripts' => [
    // @basset <- this thing right here
    // 'js/example.js',
    // 'https://unpkg.com/vue@2.4.4/dist/vue.min.js',
    // 'https://unpkg.com/react@16/umd/react.production.min.js',
    // 'https://unpkg.com/react-dom@16/umd/react-dom.production.min.js',
],

That @basset would instruct basset to search for links on the following lines...