Include js file with defer or async property

I’m developing a theme for OJS

I want to include js resources in head of the page instead of at the bottom of the body to be more compliant with the modern styleguide, but to do this I need to include that resource adding the property defer (or async in some case).

For example:
$this->addScript('bootstrap-bundle', 'js/bootstrap.bundle.min.js');

will render in footer.tpl (where I placed {load_script context=“frontend”} ) this line:
<script src="" type="text/javascript"></script>

but I want to move that inclusion in headerHead.tpl, to do that I need to add to the rendered html line the property defer to prevent it is executed before the document is fully loaded and rendered:
<script src="" type="text/javascript" defer></script>

does it exist a way to do that?
Something like this:
$this->addScript('bootstrap-bundle', 'js/bootstrap-italia.bundle.min.js', array( 'property' => 'defer' ));
(of course this last line of code doesn’t work)

In the Plugin Gallery, there is the Custom Header plugin which allows you to do that.

Sure, that’s a possible solution for a specific website, but I’d like to be able to introduce this configuration directly into the theme, so that by activating it, it’s not necessary to write the js inclusion by hand.

Theme plugins are usually for loading and compiling .less files to CSS, not for injecting JavaScript, although it is not impossible as you can see from PKP’s theming guide. However, from a developer’s and maintenance viewpoint, I would restrict plugins to one functionality only and not overload them with too many differing functionalities. So why not use what is already available, very flexible (headers and footers can be saved per journal) and with what you don’t have to modify the templates.

Anyway, you would have to enter the JS code in the Custom Header plugin only once and it will be saved in the plugin settings table of the database. If you had to modify a theme plugin, this would be much more complex and difficult to maintain (testing, debugging, documenting the code change, checking in-and-out to a software repo).

In my opinion, the only point that speaks against the Custom Header plugin is that an unknowledgeable journal admin could delete or overwrite the header or footer field.

I get your point, but I prefer the opposite approach: all the customizations in a single plugin (html, css, js and any changes to the backend), in this way I have them on files in a single object instead of scattered in the database and above all I can version them. In this way I can activate a new magazine by recycling the previous work and reconfiguring it in one place instead of installing many plugins and configuring them all one by one.
Anyway this is a theoretical discussion, the point is that it can’t be done, I take note, I prefer to do the same thing hardcoded into headerHead.tpl which is pretty much what Custom Header does.
Thanks for the feedback