User tests: Successful: Unsuccessful:
Pull Request for Issue # .
Kinda replaces #36906 (no FA upgrade to v6)
Status | New | ⇒ | Pending |
Category | ⇒ | JavaScript Repository NPM Change |
Labels |
Added:
NPM Resource Changed
?
|
Category | JavaScript Repository NPM Change | ⇒ | Administration com_media NPM Change JavaScript Repository |
Title |
|
Title |
|
No, they are correct. It’s the result of npm run lint:js — —fix
The silent upgrade of choices.js is a b/c break
The silent upgrade of choices.js is a b/c break
it wasn't silent, check the description. Also fixing XSS is ok even if It breaks things (security is always no1).
Anyways I think someone else should try, IU had my fair chances and it didn't worked out
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2022-03-12 11:08:38 |
Closed_By | ⇒ | dgrammatiko |
@HLeithner for reference I saw it coming and tried to fix things here: #33773 but people were against it
ok but why do you close this PR if you only write in the title that you fix the math.div deprecation?
If it's a security thing you should report it to the jsst.
If it's a security thing you should report it to the jsst.
There's nothing to report again, I raised my concerns when the choices was introduced to J4. Also there is no real B/C break as the default behaviour still allows innerHTML according to their docs:
This behaviour has been deprecated. The new option allowHTML has been introduced, with the current default to true.
Ref: https://github.com/Choices-js/Choices/releases/tag/v10.0.0
I would say that's a b/c?
As a result of this change, callbackOnCreateTemplates now receives the full configuration object, instead of just classNames. The method signature to match previous versions is now ({ classNames }, data). See the documentation for the updated example.
I would say that's a b/c?
Did you or anyone else used the callback? Theory says yes this is B/C break, practically there are close to 0% changes that someone will be affected by this, or any of the changes due to the upgrade
that's the problem I can't say it so I can only read the b/c and then I can say we are using semver for js or not.
It's not possible for me to check all dependencies if a b/c break would happen for us or any of our users.
But as always please join the discussion if and where Joomla should use semver joomla/rfc#29
if you think semver is (partly) a bad idea then please share your opinion and we may remove semver for Joomla if this fit better the needs for our users and us.
But just making exception everywhere doesn't make sense that mean we don't make semver but only saying we do and break things expected for users. If it's a security thing then the jsst have to solve it (or course with your help).
The solution can be we update to 10. or backport the fix.
The solution can be we update to 10. or backport the fix.
There's another option:
tbh I don't understand what you mean? removing choices? and what has it todo with the scss in this case?
@HLeithner check #37255
Also have some tests and either merge it or if it goes out of sync close it. I spent more time that I'm comfortable in this one.
Thanks
Thanks, I reported the XSS to JSST in your name.
I guess the vue file is wrong?