lsp-tailwindcss VS melpa

Of course, there's already a package for TailwindCSS using LSP. With Doom Emacs installation instructions as well!

As far as out-of-the-box support, I think it works great. Much easier to configure than lsp-mode.

However, for my uses with a Ruby/React+TSX setup the performance was lacking on a large codebase. I swapped back to lsp-mode and the experience felt smoother.

IIRC the author's stance on previous discussions around multiple language servers was to rely on flymake instead, since the previous discussion centered around ESLint + TypeScript. Tailwind is a bit of an issue in the ecosystem right now, but you may want to try https://github.com/merrickluo/lsp-tailwindcss.

I am trying to use lsp-mode for ruby via solargraph and for Rails era templates using web-mode via lsp-tailwindcss and both seems to kinda sorta work but neither one is really giving me all the features that I see that others have.

There is https://github.com/merrickluo/lsp-tailwindcss and AFAIK it shows colors but Im not 100% sure. Need to check it when I'm back home.

This past September I reported to lsp-tailwindcss that their package somehow unbind C-c p p from projectile-switch-project, the developer was clueless since their package indeed does not define keys or anything, I had no remedy than deactivating it.

Watch the new pull requests to melpa: https://github.com/melpa/melpa/pulls

(require 'package) (add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t) (package-initialize) (package-install 'use-package) (use-package exec-path-from-shell :ensure t :config (exec-path-from-shell-initialize)))

MELPA is definitely the biggest package archive, probably mostly on account of the lower barrier to entry compared to GNU ELPA (maybe the difference would have been less pronounced if NonGNU ELPA had been there from the beginning, but one can only speculate). MELPA has its own requirements for packages, but indeed copyright assignment to the FSF is not one of them.

I would suggest to start at reading the manual first. Then I would recommend reading the Melpa guidance, even if you do not plan to contribute your package to Melpa, since it contains very useful info about linting, writing your code etc.

The mxtoolbox link checks for SMTP blacklisting.. People won't be able to send mail from host with the IP address 178.128.185.1(which is the melpa.org webserver, not their mailserver, so everything's fine there).

Xah asked for his packages to be removed from MELPA a while back: https://github.com/melpa/melpa/issues/7755

Observe that package.el compile files when they are installed, and they are not compiled in any particular order (actually whatever directory-files returns, which is what OS returns). So if you have multiple files that depend on each other, it is something to think of. There are also some guidelines on how to structure your project on Melpa.