package-lint VS compat

Exactly! This is also why I like Compat. I have to read through the Emacs NEWS anyway, then I can just as well add the functions directly to Compat. The small downside however is that Compat pretends that some function is available in your Emacs. If you write a package you must look twice where a function is coming from. This should not be a problem if you use package-lint, which you should! But see also https://github.com/purcell/package-lint/issues/227.

Thank you for reading that far. If you have feedback, questions or improvement proposals, please let me know. I hope that Compat is useful for you. If you miss some important functionality, feel free to open an issue on the issue tracker. Any help in adding missing functionality is welcome. In case you are interested in upstream development, you may want to help with scanning through years of the Emacs Git log for added functionality. A laborious process, but the Emacs library diffs from package-lint are useful. Unfortunately package-lint does not yet support Compat and warns if you use compatibility functions. Also package-lint does not yet track argument number changes. Help with those package-lint issues would be greatly appreciated.

I would suggest using the checkdoc command in each of your package buffers. It will point out stylistic errors. flymake-mode will help catch byte-compilation errors as well. You should also install https://github.com/purcell/package-lint and M-x package-lint-current-buffer to get these up to par for MELPA.

(Note that the current minimum requirement for Emacs is set to 27.2, I'm pretty sure this can be lowered but I'm waiting on this issue for confirmation. Until then, if you have an older version, you should probably be able to install with quelpa just fine).

Also consider using checkdoc and package-lint before you publish stuff, it is really annoying to get warning pop-up for docs wider than 80 chars. Those are so easy to catch up. Generally, it is good to follow Melpa guidelines even if you don't plan to publish your package in Melpa.

I strongly suggest you to use package-lint when writing packages. It will point out all version mismatches, and some other things.

With the Compat library you can use define-keymap right away in your packages. See also my post about Compat.

Exactly, I think printing a loud warning is a perfectly acceptable solution. The note should ideally tell the user to ensure that dependencies are met. It makes sense to teach users a little better about the limitations of Straight or Elpaca with respect to dependency handling since I've seen many reports across the ecosystem where people didn't properly update dependencies. I usually bump dependencies when I really need new functionality. In particular with our Compat package, versions are meaningful and should be respected.

Compat co-maintainer here. Thank you for writing this post! One minor correction: Compat supports Emacs 24.4 and newer. Please link to the upstream repository at https://github.com/emacs-compat/compat instead of the Straight mirror, since the mirror does not preserve the Git history.

As /u/usaoc said, ensure-list can be used for this purpose - I use it all the time in my packages. I recommend to take advantage of the Compat package from GNU ELPA, such that you can use all new Emacs APIs even in packages targeting older Emacs versions. I am the maintainer of Compat. See also https://www.reddit.com/r/emacs/comments/10iep0o/compat_29130/ for more background.

I released version 29.1.3.0 of Compat, the Elisp forwards-compatibility library on GNU ELPA. This library may be interesting for you, if you want to use newer Emacs developments in your packages without breaking backward compatibility with older Emacs versions.

I updated some packages which included updating the dependency compat.el to 28.1.2.0