Add HTMX dependency to core

few comments on the MR

MR is updated. Leaving as "active" until we have the security policy resolved

Code is good to go for me, we can RTBC once the security issue is managed. To be more accurate the status should be postponed since we're waiting on external third party for a reply :)

nod_ → credited 1cg → .

Crediting htmx maintainer for resolving the security policy issue

I confirmed the security policy was there as well.

I tried to follow the instructions to report a security issue, but the report a security vulnerability button was not there, I pinged @1cg on slack about it and he enabled the security reporting.

We should document this bit for future dependency evaluations so that it's easier to onboard projects.
It seems for github anyway there are two steps. Here is the documentation page on github: https://docs.github.com/en/code-security/security-advisories/working-wit...

formatting change in the issue summary.

Also need release manager sign-off, which I don't see here.

I very reluctantly worked on the jQuery 4 port of jquery.form.js because it was one of the last blockers to releasing Drupal 11. While the AJAX system works, it has a lot of custom and long-unmaintained JavaScript behind it and is one of our heaviest jQuery dependencies. There has been no progress in modernising any of that js in the past 10-15 years.

The plan to introduce HTMX alongside the AJAX system as a new API means we can ensure feature parity and improve APIs, but without having to try to implement complex JavaScript or BC layers - instead running both side by side until we can fully deprecate and remove the AJAX system.

I very reluctantly worked on the jQuery 4 port of jquery.form.js because it was one of the last blockers to releasing Drupal 11. While the AJAX system works, it has a lot of custom and long-unmaintained JavaScript behind it and is one of our heaviest jQuery dependencies. There has been no progress in modernising any of that js in the past 10-15 years, instead we're left with a custom fork of an unmaintained GitHub repo.

The plan to introduce HTMX alongside the AJAX system as a new API means we can ensure feature parity and improve APIs, but without having to try to implement complex JavaScript or BC layers - instead running both side by side until we can fully deprecate and remove the AJAX system.

So from a release management point of view this will eventually be a large net reduction in our JavaScript dependencies and while there are details to figure out the transition plan is good.

I think this needs FEFM rather than FM review so switching the tags over.

+1 for this, validated that in #3404409-99: [Plan] Gradually replace Drupal's AJAX system with HTMX →

We have test failures that seem unrelated to this work: https://git.drupalcode.org/issue/drupal-3520723/-/pipelines/481254

Tests passed 🎉

Indeed, it is green now ✅ thanks to @nod_ https://git.drupalcode.org/project/drupal/-/merge_requests/11928/diffs?c...

I will take care of this today.

Does this need a change record?

I would recommend that not this child issue, but 📌 Process attachments (CSS/JS) for HTMX responses and add drupal asset libraries Active carry the change record. My reason is that although this adds the library, without the ability to bring in dependent CSS/JS it's not really usable yet. HTMX natively has properties to merge header tags but that clearly misses a lot of our JS.

If someone with more familiarity about the expectations around change records thinks that 2nd issue would be better place, I'll move the tag.

I would think both issues would get one.

We didn't have a change notice to say a library was added (like sortable and such), only the issue when it's actually used has a change notice.

For now we don't want people to use it as-is, we need to integrate it to make sure things like security and performance are taken into account.

Yeah agreed with #37, we can add the CR when it's more meaningful, but retrospectively add this issue to it then for context.

Committed 216a91c and pushed to 11.x. Thanks!

Someone with more permissions must be needed to edit the JS Dependencies → page. I don't know if someone edited source or there are other text filters available, but I can't add additional headers and rows to the existing table.

Here's the needed data:

Repository https://github.com/bigskysoftware/htmx
Release cycle Releases are expected quarterly.
Security policies https://github.com/bigskysoftware/htmx/security
Security issue reporting https://github.com/bigskysoftware/htmx/security/advisories/new
Contact(s) 1cg → , fathershawn →

Assigning to myself to sort out the documentation.

I made an entry for HTMX at Current JavaScript dependencies → and completed it from the information in the issue summary. Update that entry as needed.

Locally when I run yarn vendor-update on 11.x I get some changes without changing anything in package.json or the lockfile:

1. assets/vendor/htmx.org is created, which is a copy of assets/vendor/htmx
2. htmx.debug is upgraded from 2.0.1 to 2.0.4

let's remove the debug extension, it's not used yet and there is a built-in way of doing the same thing (htmx.logAll())

as for the folder that's my bad, I removed the "folder" key and we needed it

Using the latest changes there are still no changes to the package file or the lock file.

This also still needs a release note.

The lock file is correct, latest version is 2.0.4: https://www.npmjs.com/package/htmx.org?activeTab=versions

The debug extension is in the package because of how they used to do things: https://github.com/bigskysoftware/htmx/blob/master/dist/ext/README.md

@nod_ I think we also need to delete assets/vendor/htmx/debug.js from the repo?

that's a good idea, follow-up though

Committed 042eb55 and pushed to 11.x. Thanks!

longwave → closed merge request !11928

maybe change record could be added here? that's very helpful

@andypost see #34-39