Remove jQuery as a dependency

darren.fisher → made their first commit to this issue’s fork.

I've had a stab at this:
Patch is here if you want to test: https://git.drupalcode.org/project/easy_email/-/merge_requests/40.diff
MR here to see differences in gitlab: https://git.drupalcode.org/project/easy_email/-/merge_requests/40

@darren.fisher, I reviewed this today, and it looks like a great start. Thanks!

Unfortunately, it doesn't work completely. The purpose of jQuery UI Resizable in this module is to make the content boxes when previewing a template resizable so you can test how emails look on different devices. After applying your MR, I found that the Inbox Preview part of the page was still resizable, but the HTML and Plain Text bodies were not. Can you update the MR so that it also works with the body fields? If we can get this working on all three boxes on the Preview Template page, I will merge this, and we can remove the jQuery dependency.

Thanks again for your work on this.

It looks like on closer inspection that we don't need javascript at all. I've resolved the resizing with css alone. Whilst I was in there I refactored the preview template and the entire css file to use modern CSS practices including logical properties and CSS custom properties so it will need some thorough testing. I also tried to standardise and clean up the spacing on the preview page. Let me know your thoughts. I'd love to do a bit of a tidy up of some of the other templates as well and set up the gitlab CI/CD runners but that feels like it's probably a separate issue to this one!

This looks great, and it's working for me in Chrome, Safari, and Firefox. We're good to go on the CSS / JS changes I think.

One major issue, though, is that we can't remove the dependency from composer.json until we make a new major release. If we remove it right away, as is done in the MR, composer will remove jquery_ui_resizable on composer update, and that's going to break everyone's sites.

I asked for advice on this in Drupal Slack: https://drupal.slack.com/archives/C1BMUQ9U6/p1742398095621039

The consensus was that we should remove the dependency from the .info.yml file but leave it in the composer.json file. Then, when we cut a new major release, we can remove it from composer.json and put instructions in the release notes about how to handle the situation. This was done for Config Split remove the Config Filter dependency here: https://www.drupal.org/project/config_split/releases/2.0.0 →

I want to wait a little bit before we cut a new major release. There are some other potential breaking changes that I might need to make, and I want to bundle them all up.

For now, can you put the dependency back in composer.json in the MR? Then, I will merge this in.

After that, I'll cut a new 4.0.x branch and put a commit in there to remove the dependency in composer.json. It might be a while before the 4.0.x branch gets a release, but whenever that happens, we'll include the complete removal in that.

That makes perfect sense. I've run into this issue several times and should have thought about it!!

All done and I've also merged the changes in the dev branch in so the MR should apply without issue!

Thank you for the prompt review!

Some new comments came in on the Slack thread I referenced above.

Since this module is part of Drupal CMS, we need to follow the status of 📌 Dependencies should be 'unpacked' to the root composer.json and merged/resolved Active .

As it currently stands, I think that if DCMS upgrades the version of Easy Email to 4.0.x, which we would want them to do for new installs, then everyone who previously installed DCMS is going to get 4.0.x as part of a composer update, even if they don't explicitly request Easy Email 4.0.x.

This complicates things. I think what we have now in the MR, where we require it in composer but not in .info.yml is fine. We just may have to stick with that for a longer period of time than I initially anticipated.

I'll do another review of this MR tomorrow, and merge if everything looks good. Then, I will open another issue to track the status of removing the dependency from composer.json.

That makes sense. I will review issue #3355485 as this isn't something I'd considered when it comes to recipes and will be a useful thing to be aware of when removing dependencies from other modules in the future.