Basset outdated/update command — An optional way for maintainers to still use NPM to bump versions?

tabacitu commented 1 year ago

We all know NPM is the devil. Buuut... it does have two benefits...

getting automatic Dependabot notifications to bump dependencies, when security issues arise;
easily updating all assets, by doing npm update;

Can we / should we provide a way for maintainers of blade files (be it package maintainers or end-developers)... to use NPM to bump versions?

At first we thoughts we could. We said "_ok, we'll just

create a config file, mapping ckeditor4 to https://cdnjs.cloudflare.com/ajax/libs/ckeditor/{version}/ckeditor.js_";
create a script that parses a package.json file and spits out an updated config file;

Buuut. I've realised that is NOT OK. Because as soon as the developer publishes that config file, the maintainer can bump versions all they want, because their new versions will NOT be used, the ones in the config file will be used instead. So this:

    NOW WE HAVE:
    @basset('https://cdnjs.cloudflare.com/ajax/libs/ckeditor/4.20.1/ckeditor.js')

    HOW ABOUT INSTEAD OF:
    @basset('ckeditor4')                                => config/bassets/file_paths.php

    WE DO:
    @basset(config('backpack.assets.ckeditor4'))        => config/backpack/assets.php (or maybe js.php and css.php?!)

Is not a good option.

But my question here... and @promatik 's question too... is...

1) Is this really necessary for the developer to EVER override a loaded asset, to bump their own version? Because if they do... that's a big risk. The maintainer of the package might push an incompatible change, and completely break their app. So it would be safest, when Basset is used in packages... to NOT let developers change what asset gets loaded (or their version).

2) Is it really that big of a deal for a maintainer to:

keep the pacakage.json file in their repo, to get Dependabot alerts;
when an alert comes, manually go to the blade files and bump the versions;

3) If we DO include NPM support... doesn't that defeat the purpose of this entire package? Like... the whole purpose of this package is to get rid of NPM from our lives.

Food for thought.

promatik commented 1 year ago

I wouldn't go with the mapping solution ... It may create confusion, by allowing multiple blades to have the same references.

I would go with a command to list all dependencies (with optional search) and choose one to update.

php artisan bassets:update jquery

[1] https://unpkg.com/jquery@3.0.1/dist/jquery.min.js
[2] https://unpkg.com/jquery-ui@1.12.1/dist/jquery-ui.min.js
> 1

Basset found in 2 places:
- resources\views\crud\reorder.blade.php
- resources\views\crud\fields\color.blade.php

Assign a new path:
> https://unpkg.com/jquery@3.0.2/dist/jquery.min.js

Done!

@tabacitu let me know 👌

tabacitu commented 1 year ago

Yeah I think so too... it'll be a little more complicated than that... like... would you also do search&replace in the vendor directory? In packages? And other questions I'm sure. But that does sounds like the better way to move forward, yes.

Let's not do anything about this YET. Let's present this to Pedro next week, and talk all 3 of us.

Laravel-Backpack / basset

Basset outdated/update command — An optional way for maintainers to still use NPM to bump versions? #8