Feature request: Process bassetBlock scripts in basset internalize command

[jnoordsij]

Currently @bassetBlock directive are ignored by the internalize command.

It would be nice to have these assets also processed when running the internalize command, to have less operations when the first request lands.

[tabacitu]

Wait. This might be a documentation problem, rather than a real one 😀

AFAIK they're only ignored when Basset is running on localhost, or when the env variable BASSET_DEV_MODE=true. During dev mode, Basset tries to do as little as possible. In production, the @bassetBlock() will get cached.

You can try that out by doing BASSET_DEV_MODE=false in your .ENV file. Then either running php artisan basset:cache or browsing the page with the @bassetBlock()

Let me know.

[jnoordsij]

I've checked on my local setup and I can't seem to get the cache command to cache the basset blocks, regardless of environment variable values. I noticed this, because I was comparing the .basset file right after running the cache command vs. the one after browsing through my admin panel, in which a few additional entries appeared.

Also, I noticed this line of code:

basset/src/Console/Commands/BassetCache.php

Line 68 in b5f6747

preg_match_all('/@(basset|bassetArchive|bassetDirectory)\((.+)\)/', $content, $matches);

My first look at that makes me think that bassetBlock directives are not handled (which I do sort of understand, since they would need a completely different kind of parsing compared to the others).

[tabacitu]

@promatik ?

[promatik]

Exactly 🤷‍♂️
@bassetBlock is much more complex in terms of parsing, that's why it was ignored. And also because @bassetBlock is faster to be internalized during the load of a page, it doesn't require any download from CDNs or stuff like that.

But, it is possible, and it's a nice to have, it was just never a priority.
@tabacitu I'll let you decide on the priority of this one 👌

[tabacitu]

Oh I get it now. I think it's a SHOULD, but not urgent. Let's do it later on in the year.