i suspect some of these plugins may need override, like coc-denite may need denite as a dependency, coc-tabnine requiring tabnine, coc-vimtex requiring vimtex etc.
For instance, I wonder if you could make coc-python work ?
Also you've mixed in vimoutliner and a.vim and some unrelated update in a single commit. It may be wiser to split this into several PRs so that one reviewer can really test the PR.

e.g.: coc-imselect should be darwin only etc

Split the PR in several commits for easier review.
All I did initially was follow the default steps of adding vim plugins:

Some of these will require extra steps indeed, however I think it's nice to at least have the extensions in nixpkgs already as a first step. (similarly how it was done for coc-nvim itself)

Just wanted to chime in and say that I'd love to see coc extensions added to nixpkgs, in fact it's been on my list to see if I could figure out how to do it myself.

As @teto notes, some of them will probably require unique overrides, and I think probably all of them that are actually extensions to coc (unlike coc-denite) will require an override in order to be properly installed. I expect the general overrides for each extension would be of the same form as the override for coc-nvim itself:

One issue that will almost certainly come up is that the overrides will be hard to keep in sync with the generated nix expressions whenever the vim plugins are updated. See PR #64411 by @teto, for an example.

Seems to me that the ideal longterm solution would be to have a separate script that generated the necessary nix expressions for coc extensions, but that seems like a lot of work.

@malob It's not necessarily a lot of effort. E.g. for coc-go something as simple as 1eb975c should be sufficient.

coc-nvim is quite an exception really since there we actually want to version it.

@rvolosatovs, hmmm you are probably totally right. I accidentally assumed that the process for installing extensions would be similar to the process of installing coc.nvim itself.

Does anyone want to contribute to this?
I won't be able to go through the plugins and add overrides any time soon.

I'd be happy contribute, but I'll need some tips about how to get started.

ok let's merge this because I know it can be a pain to rebase the vim generated plugins.
I hope there will be some follow up PRs to make the different plugins work out of the box as much as possible.

@malob you can just look at pkgs/misc/vim-plugins/overrides.nix and try to adapt these to the different plugins.

I have no idea whether this comment will be noticed, but I want to gently and respectfully ask whether merging this PR in an incomplete state was the best course of action.

I don't know how many other people may have run into this problem, but I've spent about two days trying to figure out why there are coc extensions in the Nix repo that have no documentation on how to use them, no explanation of how they are loaded by coc, and ultimately (as I found out the hard way) don't work. This time is on top of the day or two that I spent figuring out why the coc plugin itself is available in Nixpkgs even though coc's documentation says that I should use Plug. Nix's relatively unhelpful wiki page on setting up vim doesn't give a clear explanation of how the vim packages work, either.

I'm a newcomer to Nix and I've quickly become aware that I'm not the only one having a hard time with the documentation. I've been trying to update the docs myself as well trying to contribute to vim plugins. I don't mean to sound ungrateful. I'm aware that most of us are doing this for free and that keeping docs up-to-date is a task that most people don't relish, especially when the code is in flux.

But why make things harder on new users by intentionally, knowingly merging broken code? Had I not stumbled on this PR by accident, I would still be scratching my head, wondering why the mainline Nixpkgs repo has these tantalizingly-named coc- packages that are essentially unusable. (Or some of them, anyway. FWIW, in the extensions that I tested, the problem is that we need overrides to add some kind of build step, as @teto observed above.)

Thank you all for your hard work. I greatly appreciate it, and I hope that we can all make the UX more hospitable, especially for new users.

I think we should just mark the broken coc plugins as such to avoid confusion for now.
After switching to coc and opening this PR I found myself not using any plugins besides vanilla coc, so adding necessary overrides fell down on my priority list.
@malob did you make any progress on this by any chance?

@earksiinni I actually stopped searching for answers in the docs and most of the time just read the source. For NixOS option I man configuration.nix first, search for the option I'm interested in(or find such) and then use the filepaths specified to read the source. For packages I just grep/(or rg in my case) the codebase. That way I can also use git blame to find relevant commits/PRs, which may have additional context.

@rvolosatovs, I've also stopped going to the docs, in part due to my struggles with coc extensions. I'm currently writing a deep dive about what exactly happens when one installs a Nix package. It has been highly informative. I follow a workflow similar to yours. (Didn't know that configuration.nix had a man page, though, thanks for the tip!)

However, I don't think that "the documentation is bad, so check the source code" is a good state of affairs for the community. Merging broken code merely compounds the problem.

I'd like to take a crack at fixing the broken extensions this week.

@rvolosatovs, no progress unfortunately, I tried a couple of times but didn't get to far before hitting issues.

@malob @rvolosatovs, I've made some progress and have fixed vimPlugins.coc-prettier on my local machine. Will post in #64560 to keep the discussion in one place.