pegjs
pegjs copied to clipboard
pegjs
Project maintenance and health
Hi @futagoza!
During the last week I was tagged in multiple issues by @StoneCypher, who expressed his worries about PEG.js maintenance and project health (he also contacted me about this privately by email). I haven’t followed PEG.js development much since I transferred the maintenance to you, but his actions made me have a look.
I have to admit the current state of the project made me sad. There are tons of changes in the code, but the last release is still 0.10.0 which I did back in 2016 (!). Apparently, you were on track to release 0.11.0 back in 2018, but that never happened. Your last comment in the issue talks about rewriting PEG.js in TypeScript instead (?). There are also multiple other, less glaring problems.
While I don’t approve @StoneCypher’s way of expression, I understand and share his concerns. At this point, I wouldn’t recommend PEG.js as a basis of any project.
As you know, when I transferred PEG.js to you, I deliberately cut all my ties to it. I wanted it to be developing independently, without my direct or indirect involvement, and without my spectre hanging over it. I no longer have any rights to PEG.js's website, GitHub, or npm package. But I feel I have to speak up now. I’d like to ask you to consider the current state of PEG.js, its future, and to think about changes to make the project healthy again.
I’m pretty sure PEG.js community shares the concerns expressed above and would appreciate an honest answer. And while I don’t want to suggest any particular course of action, I believe the community may be the key to resolving project’s current problems.
I hope you won’t take my message in a bad way. I know very well that maintaining a project like PEG.js is hard and one can’t satisfy everyone all the time. It’s just that I felt my word may prompt you to think about these issues and that PEG.js community deserves an answer.
Thanks for listening.
I despair that I have to fork this library, meaning none of the existing consumers will ever get help, and one of the most important libraries on the internet has died
RIP
On Tue, Feb 18, 2020 at 5:59 AM John Haugeland [email protected] wrote:
I despair that I have to fork this library, meaning none of the existing consumers will ever get help, and one of the most important libraries on the internet has died
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pegjs/pegjs/issues/639?email_source=notifications&email_token=AAAETTRJGY4Q5AWE76RBM2DRDPSURA5CNFSM4KSDGYBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMCCBUA#issuecomment-587473104, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAETTRC57XZWSLTNS3VLL3RDPSURANCNFSM4KSDGYBA .
I used this library 5 years ago when I still learning to code JS. I made a language that render to HTML that is more expressive than any Markdown dialets I knew. Today, I reconsidered that language to be further evolved, but to find out this library is not as healthy as I'd expected. Just feel sad.
My company uses this package as well and very much like to see the ES module feature and the TypeScript language feature released soon.
If @futagoza can't maintain this package anymore, he should let somebody else take over.
I’m pretty sure PEG.js community shares the concerns expressed above and would appreciate an honest answer.
More than two months, and still no answer?
It looks to me like @futagoza has fallen: all activity on the various communities his linked homepage links to stop at about the same time. Sad.
I've reached out over e-mail to see if @futagoza could use some help with community management. I think it would be best if we could find some folks who are interested in doing maintenance releases on v0.10 and a few folks to work towards v0.11.
Please remember to be kind and let's all do what we can to help out. If anyone has other ways to get in touch, please take some time to reach out and let's see if we can lift the burden and work together.
This request to @futagoza for community help has beed raised may times, but we got no response on that matter. We can only assume this project as abandoned, and together decide on a fork to work from there.
I got a response to e-mail. I'll follow up as soon as I have more info to share.
We shouldn't release 0.10. It's been put onto really weird isolated tools, the development methodology has been changed to something bizarre and niche, it's been moved onto failing build systems, &c.
We really need to go back to 0.9 and cherry pick PRs in their original state, and keep David's original clean system. We can't let Futagoza skip versions for three years because he's created a mess, then hold out for someone who's willing to keep his approach and try to release it
This needs to be turned into a standard node system now. It's needed it for years and all the active users have been asking for this forever
@StoneCypher I think you may have missed something or it may just be a typo - we already have a 0.10 release. So you meant the 0.11 release?
@tilgovi Any news to share?
In general: is there another parser library anyone can recommend?
Frankly none of those are usable.
None of those except canopy and ohm have an in-browser version
Waxeye slows down dramatically under even light use, as does apg
Jison's grammars are a puzzle from Vulcan, set to drive any human that isn't Lex Luthor stark raving
ANTLR is like eating broken glass that is somehow also bees
Nearly is fun and interesting and I just cannot get the promises that Early parses give. I recognize that I should be able to. I've been trying for years.
Ohm is super powerful and fun and an entirely different way of looking at the problem and not a reasonable substitute. It's like recommending a replacement of lisp with prolog. Peg and Ohm only just barely technically apply to the same problem domains. It's almost guaranteed that at least one of them will be a bad fit.
Bennu is buggy and produces incorrect results.
Parsimmon is interesting and powerful but I don't enjoy parser combinators and it's pretty verbose.
Par.js took the first ten lines of my PEG and turned them into 200 lines of code. Ouch
Chervotain made them 1900 lines. I actually wrote a peg to translate my peg to Chervotain. Admittedly, it's blazing fast, but the last thing I want to do is transcompile a grammar, and the second to last thing I want to do is maintain Chervotain. Even the XML guys would call this verbose.
The reason PEG has persisted despite rotting on the vine half a decade is that nothing currently alive can possibly replace it.
I initially got a very thoughtful response when I reached out over e-mail. I suggested ways I could help the community get started maintaining a 0.10.x branch and offered to work on reviewing and managing contributors. It's now been weeks since I last received a response.
Ya'll i think it's time we stop grumbling in the issue tracker here. I also want to see the project move forward but Maintainers don't owe us anything. The better approach would be for someone to fork and maintain in the way they feel is best. We need to show up or move on though, there isn't much value in grumbling about other's free work. Clearly they don't have the time, energy, or desire to keep the project moving, and that's fine!
i'd be all for a new maintained fork under fresh administration -- it should be called POG.js am i right fellow kids?
If I were @dmajda I'd be pretty upset to be honest.
I’m not really upset, but I regret not doing two things:
-
Not waiting longer before handing PEG.js over to a new maintainer. Maybe I should have waited for multiple candidates to appear and choose between them, require contributions first, or something similar.
-
Not keeping the “keys” to the project (access to PEG.js website, GitHub, and npm package).
Any of these may have prevented the current situation. Unfortunately, this is obvious only in retrospect.
Anyway, it’s quite clear from his non-reaction that @futagoza is not interested in PEG.js anymore. I didn’t watch the JavaScript parser generator space in the last few years so I don’t know whether a good replacement of PEG.js exists. But if not, I would welcome if someone sufficiently interested and motivated picked up PEG.js code and continued development under a new name. I believe this would be the best course at this point. The only issue to decide is whether to continue from the current state or from the state before changes made by @futagoza.
I think that changing the name is a good idea in order to prevent confusion, at least if the original website and repo is still up. Also, it is possible that multiple people will appear, each wanting to take PEG.js in a different direction. In such case, it would be unfortunate to have “Joe’s PEG.js fork”, “John’s PEG.js fork”, etc.
I feel sorry for this situation. If I ever do an open source project again and end up handing it over to someone, I will definitely do it differently.
Not keeping the “keys” to the project (access to PEG.js website, GitHub, and npm package).
Hello.
I don't know about the website and github access, however, npm has a process to resolve conflicts on package names.
- https://www.npmjs.com/policies/disputes
So that is one item that can be retrieved.
Who is paying for https://pegjs.org DNS name? If I understand correctly the domain name will expire in ~1 week so dependent on the grace period it may be possible to repurchase pegjs.org in 1-2 months.
@bd82 - we cannot dispute this because there is no cause. dmajda chose to give the project to someone who's never done anything, and that person has absconded.
@phpnode - I have a significant modernization of the project underway
@StoneCypher sounds good! Is this on your fork at https://github.com/StoneCypher/pegjs ?
I've contacted the owner of the https://www.npmjs.com/package/peggy package which hasn't been updated in 9 years and they've agreed to give us the name. I've created a new github org and moved the repo here: https://github.com/peggyjs/peggy I'd be happy to add you to the organisation if you'd like?
I would enjoy to join your org.
No, that's not the one I'm talking about; that's just a bugfix fork for the main project. I already have a domain and package name :)
My goals are to modernize the output and editor, to fix a lot of long standing bugs, to radically improve testability, and to fix the enormous !#%%#& binaries I get unnecessarily
You can dispute whatever you want with npm, they are usually very helpful, you don't need "cause" to contact support over package ownership, it's not a legal proceeding
The NPM people have clear guidelines on when a repo can be contested, and this unfortunately does not fit.
Listen, think about it. If every time a repo went dark, any rando could come take it over, you'd be looking at an extreme security nightmare, where any time someone wanted to attack people, they'd just pick some random supporting library that was cold and be like "I want to be the new maintainer"
Their process is for things like abuse, trademark control, and things of that nature
if you say it's useless before trying that's fine guy. I don't care. I've had luck talking to them about conflicts and they have been very helpful without it having anything to do with trademark issues or things of that nature, if @dmajda would like to try, it's just firing off an email. The worst case is they say no and you lost 5min of time.
The npm name disputes policy explicity states that the process may be used to:
Adopt an "abandoned" package
- https://www.npmjs.com/policies/disputes
I would recommend attempting this process, there is enough proof that the package has been abandoned...