User tests: Successful: Unsuccessful:
Pull Request for Issue # .
The Browserlist db needs to be updated periodically.
"browserlist:update": "npx browserslist@latest --update-db"
Check the npm action on the drone:
Please select:
Documentation link for docs.joomla.org:
No documentation changes for docs.joomla.org needed
Pull Request link for manual.joomla.org:
No documentation changes for manual.joomla.org needed
@HLeithner @wilsonge @Hackwar please check the action part, you might need to tweak it
Status | New | ⇒ | Pending |
Category | ⇒ | Repository NPM Change |
This is the library that nearly everything uses to power the js/css build tooling to compile for the right versions https://github.com/joomla/joomla-cms/blob/4.2-dev/package.json#L30-L33 here. You'd use the same thing for webpack/rollup/parcel etc. So yes it's definitely required. What browser thing do we have in composer? Not aware of one?
The thing we use composer for regularly is the CA Cert list updates
Testing should be easy: npm ci before applying the patch, make a backup of the media folder then apply the patch and run npm ci and then compare the 2 folders.
About https://github.com/joomla/joomla-cms/blob/4.2-dev/package.json#L30-L33 I guess you could copy the browser list from Bootstrap which is less radical https://github.com/twbs/bootstrap/blob/main/.browserslistrc. FWIW js is not really impacted here as the tools compile to es5 for the no modules/legacy and es2018 for the modules
Makes no sense, if it's not already done in the build script
Objection! Sorry @HLeithner but that would create a huge disconnect between what people actually tested with what the project will release. Let me explain:
so anyone that either downloads the package from a PR or they run npm ci
they will use the same db entries as the one that the project will use for the production
FWIW George spotted this when I was updating the custom elements repo, thus the PR here
OK then it can only be done like the composer update in a minor release.
OK then it can only be done like the composer update in a minor release.
I'm not the one to tell you what the frequency that the action should run. Although since my idea was to automate this it implies that it should run more frequently. As I said copy the https://github.com/twbs/bootstrap/blob/main/.browserslistrc from the Bootstrap repo (which is anchored to specific versions) and let the action run as frequent as possible.
Also a bit unrelated bu since I was checking the other actions I think you should manage the node version and the base branch using the repo's secrets. That way you don't have to touch the actual scripts when either of those is changed, eg:
node-version: 16
becomes node-version: ${{ secrets.NODE_VERSION }}
-base 4.2-dev
becomes -base ${{ secrets.BASE_BRANCH }}
and you need to add NODE_VERSION
, and BASE_BRANCH
in the secrets (with values 16
and 4.2-dev
). Then for 4.3-dev you just update the values in the UI, not touching the actual scripts.
So we can you remove the github action please and only keep the browserlist:update
command?
I added the step to the beta1 of a minor/major release in the release checklist documentation https://github.com/joomla/internal-documentation/pull/24
Labels |
Added:
NPM Resource Changed
?
|
Category | Repository NPM Change | ⇒ | NPM Change |
@HLeithner done, only the script is left here. Btw I don't have access to the internal docs repo but I trust you and George are getting it right
Status | Pending | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2022-11-27 09:03:03 |
Closed_By | ⇒ | HLeithner |
Thanks, and I invited you
Makes no sense, if it's not already done in the build script then it should be part of the build script like the webauthn update. Also we update the browser list in composer, is this another needed list?