Project Dead?

[cjancsar]

Looks like this project is dead. Is there any active alternatives?

[DanielRuf]

Maybe I will create a fork then.

[DanielRuf]

https://github.com/DanielRuf/esdoc-next

[cjancsar]

@DanielRuf ok thanks. I would probably be up to helping you maintain the fork. What do you think the first steps are?

• Review open PRs to see if they are good fits (if not features)
• Review and merge any bug fixes
• Update Docs to host elsewhere
• Get the lib packaged and publish on npm under new name

I am interested in getting this project active again, and abandoning this abandoned repo. From other closed issues it is clear the original maintainer has no intention of being open to contributors, or is even around.

Anyone who reads this, https://github.com/esdoc/esdoc/ is dead

[DanielRuf]

Review open PRs to see if they are good fits (if not features)

Definitely

Review and merge any bug fixes

That was my intention

Update Docs to host elsewhere

This too

Get the lib packaged and publish on npm under new name

Part of the plans

[itsjamie]

If anyone is interested, there is a fork up at https://github.com/itsjamie/esdoc-next. It is published and available on NPM for anyone who happens to need these changes. But, I don't intend to actively maintain the work beyond what is needed for any projects that I'm working on.

Changes below I made if anyone is interested, or looking from a jumping-off point for their own work.

• Updated to use Babel 7
  • I needed Babel 7 support so that I had access to @babel/parser support to parse TypeScript code along with proposals like Optional Chaining and Nullish Coalescing.
• I merged the histories of esdoc-plugins and esdoc repo into one mono-repo managed by Lerna
  • Will make further changes easier to manage across the plugins.
• Split esdoc library and CLI into separate packages. (esdoc-core, esdoc-cli)
• Plugins that directly use esdoc-core define it as a peer dependency.
• Added the new proposals to the ecmascript-proposals-plugin from Babel 7.

[DanielRuf]

Sorry but this is not a fork @itsjamie and you do things before they are discussed with others. For example the versioning should be continued.

But, I don't intend to actively maintain the work beyond what is needed for any projects that I'm working on.

And that is my main concern. So this is no actively maintained fork.

[itsjamie]

So this is no actively maintained fork.

Yes. Correct.

I was informing folks that someone had done work they could pick up from if they had the same needs as I did.

[fkm]

Sorry. But, after reading this multiple times I'm still not certain.

Is there any actively maintained fork of ESDoc?

I would gladly help with maintenance and PR reviews. But I don't want to run into the next abandon-ware project.

[DanielRuf]

Is there any actively maintained fork of ESDoc?

Not really sure. See https://github.com/esdoc/esdoc/network

I do not know if I have the needed resources to continue with https://github.com/danielruf/esdoc-next but I could try and move it to an org if more are interested to work on this together.

https://github.com/DanielRuf/esdoc-next/commits/master

I would not reset the version number like it was done at https://github.com/itsjamie/esdoc-next/commits/master?after=b13f64965fdf63dca4a3be76b99ded6e1f5254b3+34

See how I continued with html-minifier at https://github.com/DanielRuf/html-minifier-terser/releases - the first new release got a major version bump but is still compatible as it is still based on the same code base. Users might be irritated if you restart with some 0.x where every 0.x release is a breaking one according to SemVer.

[DanielRuf]

If @itsjamie is interested I would invite him to create a roadmap and plan for the monorepo migration (but please let's do not continue with 0.x - which might produce issues with changelogs, tags, ...) and might conflict with later versions.

But first we should merge some PRs and resolve issues to fix bugs and deliver updates so people can easily update / migrate without fear of breaking projects. This would include some 1.1.x and 1.2.x releases.

I think we can also move to GHA for faster CI builds.

[fkm]

Nice idea with the network page! 😎

I think I'll have a look at esdoc2.

Concerning your other points:
I concur that continuing the project and version numbers would be the right way to go and think that an organisation would be a great way to guard against abandonment because one person went silent.

[DanielRuf]

Well, esdoc2 had the last change in 2018 and I think I also checked it. They have other bugs / issues to resolve.

I think we should merge esdoc and esdoc2 in a new project. But I'm not sure if this is the right approach. I would like to continue the versioning as best as possible.

https://www.npmjs.com/package/esdoc has about 40k weekly downloads
https://www.npmjs.com/package/esdoc2 has about 7k weekly downloads

So I think we should continue the new projects from esdoc as it is adopted and used by more projects and applying strict SemVer would ensure that former esdoc users will likely switch to the new project.

[DanielRuf]

I have created a new org and moved the repo to it: esdoc-next/esdoc-next

@fkm and @itsjamie have received invitations. If there are others who want to join at this stage, please let me know.

Also please let's discuss the next steps before we do anything - don't rush =)

[DanielRuf]

I'm also not sure if the GitHub project is sufficient or if ZenHub (https://zenhub.com/) would be more useful in the longterm. We'll see then.

[fkm]

What intrigued me about esdoc2 is that there weren't many PRs open. But a look at the closed ones shows that there weren't many incoming to start with 😄

Thank you for the invitation! 😎 I'll have a go at it tomorrow.

I'm not too psyched about ZenHub. The tool itself looks nice but as this is something we'll be doing on the side I think an external ticketing system would work against us.

[fkm]

Ah. And I totally concur that we should not rush things!

[DanielRuf]

What intrigued me about esdoc2 is that there weren't many PRs open. But a look at the closed ones shows that there weren't many incoming to start with 😄

Ratios are often helpful metrics (contributions, open/closed issues and PRs, ...).

I'm not too psyched about ZenHub. The tool itself looks nice but as this is something we'll be doing on the side I think an external ticketing system would work against us.

I would just use the roadmaps and epics there but you are right, it is probably too overcomplicated. In general it is not a separate issue tracker as it is directly connected to GitHub - you can create and manage issues from and for the GitHub project, this is synced.

[fkm]

I honestly only looked at the pictures and didn't read about the GitHub integration 🙈 That could indeed help to remove the burden! Let's try it 😃