You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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...
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).
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;
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.
The text was updated successfully, but these errors were encountered:
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.
promatik
changed the title
An optional way for maintainers to still use NPM to bump versions?
Basset outdated/update command — An optional way for maintainers to still use NPM to bump versions?
Feb 27, 2023
We all know NPM is the devil. Buuut... it does have two benefits...
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
ckeditor4
tohttps://cdnjs.cloudflare.com/ajax/libs/ckeditor/{version}/ckeditor.js
_";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:
Is not a good option.
But my question here... and @promatik 's question too... is...
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).
Is it really that big of a deal for a maintainer to:
pacakage.json
file in their repo, to get Dependabot alerts;Food for thought.
The text was updated successfully, but these errors were encountered: