-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Future of remark-abbr #514
Comments
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 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. |
Hi Stalone, Yes, that sounds like a very good way forward. I'd be happy to have a look at integrating the plugin here, if you're happy to receive it. This feels like a better home for it than my personal respository - as you say, you've got a strong track record of maintaining these projects for a good long time. I'll have a look at your setup and try to match it as closely as I can, it might take me a few days to get around to it though, as I'll have to do the work in my own time (rather than my employers). I'm happy to try and put some ongoing effort in to maintenance too, but I don't necessarily need any fancy maintainer status or anything like that. I'm happy to contribute code from a fork. Thanks a lot, looking forward to working with you! Cheers, |
Glad to hear that you are ready to work on this. There is no hurry, so please take the time you need, I understand that working on one's spare time can sometimes be complicated. Also, I can't emphasize this enough: please ask any question you may have, here or on a Pull Request, and I'll be happy to answer. |
Hello @richardTowers , were you able to make any progress about the integration of your |
Hi folks,
As discussed in #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!
The text was updated successfully, but these errors were encountered: