StaloneLab
commented
1 month ago Hello, maintainer of the repository here.
When I commented on this topic of the migration in the past, my opinion was mainly that there is no reason for the migration to take a long time, so I was mostly against releasing the already-migrated plugins, especially considering that this would be more complicated for us to maintain two codebases (we still depend on the old ones ourselves, until every single package in this monorepo is migrated).
At a point, noting that some people might be interested in contributing, I then said that if they did, they I would be ready to review their merge request, and release a new version of the package. This has not changed, and will likely not: anyone wanting to contribute here is welcome, and I will even take the time I don't have to help.
That being said, I just mentioned it: I have almost no time to dedicate to this project. I am still ready to fix some issues, and promised to maintain everything here and remain available for issues until someone else takes over, or I no longer have the material ability to do it. This means that any code transferred here will be kept maintained as much as I can.
Because I know that the promise will be kept, and that it has been so for the last five years or so, I could not consider giving ownership of the packages to anyone else, especially outside of the host organization (Zeste de Savoir, where some other people have access but never publish), and I still want all of the code which gets published to NPM to be part of this repository. This does not mean that I am not ready to share publishing accesses: I do not need to be the only one maintaining one or some of the packages here.
So I will have a look at your plugin, but I have a question for you: would you be ready to take the step to integrate it here (please use next branch for now)? This would I guess require mostly work on the tooling if you used something different than us, and if possible the unit tests written on our side should be able to run (even if some fail). I think it might not be very hard, and you can ask me anytime.
From there, I would be ready to publish a new major release of this package with your changes, and will also start to publish the few plugins we already have developed on our side (three of them maybe? The list is given in the issue you mentioned). There is in my opinion no reason whatsoever to hold this code anymore, especially since I am not sure that the migration will end one day, as there is little incentive on our side. That would allow using the new packages, which are quite thoroughly tested (every one of them has a specification and tests for it).
I understand that maybe this is asking too much, but since I know that I will not take the time to integrate the package here myself, I can only suggest this option, and would indeed love it to happen. If this is not possible for you to do, then I'm afraid we'll stick to the option of keeping a private namespace for your package.
Regarding the maintenance burden, I think this is a non-question: if everything is integrated in the workflow, then maintenance of this extra piece of code is likely nothing compared to everything else we have, so it is not a problem for me, and getting the code here does not mean that you have to abandon it: further merge requests would be welcomed.
I hope that you might be ready to take this extra time, and maybe to help with the maintenance afterwards, even I must say I have little expectations since to this day none of these initiatives got to the stage of a merge request. Thanks for opening the discussion. – Stalone
richardTowers
Hi folks,
As discussed in https://github.com/zestedesavoir/zmarkdown/issues/416 there are a number of remark-plugins which are not yet compatible with remark@13, and users are encouraged to port their own plugins.
I've put together a remark-abbr plugin. The implementation isn't entirely compatible with zmarkdown's version (e.g. it doesn't support expandFirst), and it hasn't been used much yet so there could be some bugs. For the most part though, I'm fairly happy with it.
Right now, it's published to NPM under my namespace @richardtowers/remark-abbr.
I'm interested in your views on options for merging the two implementations. I think the options are:
I'd be happy with any of these options. It would be nice for users looking for remark-abbr to get a version that supports the latest remark, but my personal use case is already met so we don't have to merge them. If (3), I'm probably not going to do a particularly stellar job of providing support for the plugin, but then hopefully the maintenance requirements should be small. On the other hand, if (2) I feel bad dumping a bunch of code on you folks to maintain.
Opinions welcome!