Lerna is largely unmaintained

[MikeActually]

Historically speaking, Lerna has had issue with consistent maintainers, even though it is very widely used. (800K+ weekly downloads from NPM - https://www.npmjs.com/package/lerna)

What are the longterm options for this package?

Can ownership be more formalized and support be? For example, I see that Stackstorm (https://stackstorm.com/) depends on this library pretty extensively. Can they take on ownership of maintaining this?

Do additional owners need to be added to the NPM package?

What is the best way to handle contributions and support, if no owners can be found? How can contributions be encouraged?

What happens to the Twitter account and website?

[mohanraj-r]

Thanks for bringing this up @MikeActually
I agree - with over 400+ open issues and 30+ open PRs (as of Aug 2020), such a widely used tool needs better maintenance.

[MikeActually]

as partially documented at #2680 . I have contacted NPM regarding the degree to which this project is maintained and indicated that there may be an ask to add maintainers to the package in NPM, so that security issues can be addressed.

There was a reply from @hzoo that sounded like it was unlikely that this package would have maintainers added nor would be prioritized for support. There is some concern that adding maintainers would/could result in a security issue (which I agree with), but what I disagree with is the thought that not maintaining this package implies that would not result in security issues (it will if existing code is discovered to be exploitable, or the package winds up being incompatible with a future version of nodejs).

@hzoo indicated that he would contact @evocateur on the matter. He also indicated that if desired, there should be a fork of this (if someone wants to take that on, that is definitely an option)

I responded suggesting that there are inherent risks of doing nothing, too and that forking may not be responsible for such a large customer base.

I also indicated that Stackstorm looks like a company that depends on this package extensively, and might be worth contacting for long term support.

I also indicated that it's clear that there needs to be some effort to identify maintainers for this project, instead of just updating it now and then.

[MikeActually]

I also wanted to mention #1172 to show that support has been difficult to find for close to 2 years on this package, yet, I haven't seen much of an effort to seek out additional maintainers.

Currently, all maintenance must go through @evocateur , since he is most familiar with the project and is one of two people with access to publish changes. Would love to hear what would be acceptable from the owners of this project to help find a LTS model for this package, instead of relying on 1 person to contribute to it in their free time.

[romainmenke]

Would financial support help?
This tool saves me a whole lot of time (and money).
If there was an option to support through Github I would do so.

[MikeActually]

@romainmenke - my correspondence with NPM and @evocateur and @hzoo led me to believe that beyond financial support, having additional resources dedicate time to maintaining this would be helpful. I'm not sure how @evocateur would like to coordinate getting more contributors involved. I see PRs sitting for a long amount of time, maybe contributors can begin providing their own feedback on PRs. I think @evocateur would be best to dictate how support can be improved, and how people can help.

He also indicated that people can fork this library, if they wish, but I think that becomes problematic, in some ways, but, if it seems like the limited support is a long term problem, having a larger degree of ownership seems like it would definitely help, considering the breadthof use of this module.

[zkochan]

Let me link my message from a different issue: #2571 (comment)

I know that some teams switched from Lerna to either vanilla pnpm or pnpm+(changesets or Rush). If you want to try it, here are some links:

• pnpm workspace
• Using Changesets with pnpm
• Setting up a new repo with Rush

If you prefer Yarn, it also has lots of monorepo features.

So I think there's no reason to search for new Lerna maintainers. The alternatives of Lerna are superior and are well maintained. If you have questions about pnpm, feel free to write in our chatroom that I created for monorepo discussions: https://discord.gg/4s8wP8

[romainmenke]

@MikeActually - Yes forking would be problematic. In the long term it would do more harm than good.
I myself, can contribute some time to review dependency update PR's, but don't have the capacity to do more in depth work.
Having a larger corp back this project would be ideal in the long run.

@zkochan Sorry to say that this is way of topic :)
People are trying to keep this project alive and linking to alternatives is not helping this discussion.

[zkochan]

Well, I just don't understand why are people trying to keep it alive. You see, this project is hardly maintained for a long time but the download stats are only growing. And there were many similar issues opened but nobody can maintain this. The codebase is too complex for a new maintainer to figure out. It requires a huge refactoring. So feel free to collapse my messages as off topic but I just try to understand what features of lerna are so valuable.

[KilianKilmister]

EDIT: @zkochan npm will also ship its first stage implementation of workspaces in the next verison (npm-v7, currently in beta)
One problem with the whole lerna situation is that it can be used in such a wide range of usecases by default. Other workspaces and mono-repo solutions require a decent amount of dev-ops experience to get running smoothly, and when people who want to start a new project usually don't have a dev-ops-dude with spare time in their back-pocket.
That being said, there are plenty of tools to help somebody cover this initial phase without much dev-ops experience. And I personally don't have an issue with letting a project with such poor maintanance fade off the map.

And there were many similar issues opened but nobody can maintain this. The codebase is too complex for a new maintainer to figure out. It requires a huge refactoring

i very much agree with that

---

continuing my comment

@MikeActually I've read through the relevant discussions about this a few days ago, and we will have to see what the result of the dispute claim will be.

That being said, PRs and issues seem to go for months without any feedback, so, I suspect it will require someone to take it over completely, at some point.

I can say right of the bat, until something changes that, i'm not going to do any work on lerna.

I'm going to continur this in your issue thread in the lerna repo because it's not the topic of this thread.

While the afformentioned managemant problem is plenty reason to me to not get engaged in this repository, there are a handfull of thing which make this project not very attractive to work on for me. (spoiler: i'm not the most convenient person to work with because of always working in an esnext environment)

1. I'm not going to write CommonJS modules. I switched to native esm when node-v13 dropped, and compared to esm, commonjs is just such a pain to work with
2. I'm not interested in providing compatability for pre-node-v10 (Lerna currently has the target set for node-v6.9). Far backward compatability has very little advantag and actively using long outdated versions has active downsides. I'm personally against providing means that could encurage staying in these outdated versions
   3 I will struggle with having to write pre-node-v14 code without a transpiler. I switched to pretty much exclusively using node-v14 at its release and before that i've been using node-v13 since its launch. I forgot many of the incompatabilities the newest features have with older runtime versions, and those i remember are things i've grown to love because of their convenience. and i would like to avoid having to work in an environment where i'm not able to use them.
3. I'm not a fan of Jest and any other test-framework that pollutes the global namespace
4. the project has a very high degree of sub-division into seperate packages, encuraging stagnancy as any major changes will be incredibly hard to implement, so much more for someone who isn't familiar with the source code.
5. I'm not sure about the extent of this as i don't know enough about the inner workings of lerna, but it's possible that lerna will have/cause issues with npm-native workspaces (coming in npm-v7, currently in beta)

[MikeActually]

I don't really have a say in all of this, but I don't see suggesting alternatives as being unrelated. If nobody is willing to fork, the maintainers do not work toward getting additional support involved, or nobody is willing to contribute to being that additional support, then, I think, there is nothing left but to offer alternatives. Personally, I just see this as an obstacle for orgs that depend on this library and it's being flagged as a security concern. I'm just trying to keep the conversation going because I feel for those people, and it seems like nothing was happening here.

I really think the maintainers need to get involved here. Really unsettling that literally nothing has been said in here for months. I know the 1 email I received definitely gave the impression that this project was not worth the time, in that case, I wish they had at least indicated here that additional maintainers were needed or that they need funding to justify the time investment. Both of those things are possible, but require their involvement to move forward.

I do think this is a very unwieldy project to just dive in and expect things to go smoothly. Getting access to the NPM distro is possible, but git would almost certainly need to be forked to do that

[warent]

I don't mean this in any negative way or to invalidate all the work put into Lerna, but I wonder if Lerna is deprecated/obsolete at this point. There's plenty of material on how to use Lerna with Yarn Workspaces together, but it's not clear what Lerna actually adds that you can't just do with Yarn Workspaces.

Curious to hear thoughts and input on this.

[goldhand]

Wow, this is all kind of frightening to digest. I've been investing a lot into lerna and I hate to see it in this state. I wanted to share some things I noticed reading through discussions:

1. It's very unclear HOW to become a maintainer - This issue Help: Call for maintainers? #1172 is calling for maintainers but provides no path for maintainers to answer the call. This issue https://github.com/lerna/website/issues/47 (that's been open since 2018) points out that https://slack.lernajs.io/ is down. I continued searching and I found this comment that mentions a lerna slack channel and so I tried to join the lernajs.slack channel and was told I needed to sign up with a @thejameskyle.com email address. This seems like a very odd barrier for interested maintainers to have to over come. I'm assuming that @jamiebuilds can elaborate on this decision because he owns the thejameskyle.com domain. I then checked out the lerna twitter account as suggested on lerna.js.org but found the last post is from 2018 and assumed any communication via that channel would be ignored.

2. Having all maintenance go through @evocateur is a huge bottleneck. This was mentioned in @MikeActually's comment Lerna is largely unmaintained #2703 (comment) and I haven't confirmed this with any other maintainers or contributors but if this is the case, this should be addressed ASAP because there's no way this can continue. This is not intended to discredit all the amazing work @evocateur and other's have done building and maintaining this project thus far.

Currently, all maintenance must go through @evocateur , since he is most familiar with the project and is one of two people with access to publish changes. Would love to hear what would be acceptable from the owners of this project to help find a LTS model for this package, instead of relying on 1 person to contribute to it in their free time.

Suggestions

If a couple small actions are taken, I think they could have a good impact on the maintenance of lerna.

Note: I went ahead and created issues for these suggestions and will move these descriptions there too eventually but leaving here for easier digestion.

1. Set up an official slack workspace (#2715) Skip the heroku hosting, just do a free one. https://github.com/lerna/website/issues/47 as evidence supporting not hosting your own on heroku. You can also use the free plan with discord.com. Either one would work. I would suggest opening up the workspace to anyone interested and then restricting access via channels for maintainers (rather than requiring users to have a @thejameskyle.com email address — with this current setup, I'm discouraged from trying to become a maintainer and unable to just poke my head in and ask clarifying questions).

   1. Create a private, invite only, maintainers channel.
   2. The general channel can be open for anyone to discuss.
   3. Maybe create help, features etc channels optionally.

2. Open up the gates for all maintainers (#2716) If @evocateur is the only gatekeeper at the moment (as mentioned in Lerna is largely unmaintained #2703 (comment)), open up the gates for all maintainers at the risk publishing regressions. This is an acceptable trade off because I believe the only alternative is to let lerna wither away before it's time was up. There are ways to mitigate this risk of course. I'm not sure what the state of the unit and integration tests are but that's a place to start. pre-release candidates are another option to help prevent bugs from entering into consumers who haven't opted in to the @next release.

3. Define migration plan if this cannot be maintained (#2717) If this really can't be maintained, the focus should be on establishing a migration path for existing consumers. I would prioritize this more after the first 2 suggestions have time to attempt to yield positive results. I am assuming the migration would be to npm workspaces.

Side note: I really appreciate all lerna does. I've done a lot of work within my company to support lerna in our internal tooling. I'd be happy to be a maintainer.

[jakebailey]

I don't mean this in any negative way or to invalidate all the work put into Lerna, but I wonder if Lerna is deprecated/obsolete at this point. There's plenty of material on how to use Lerna with Yarn Workspaces together, but it's not clear what Lerna actually adds that you can't just do with Yarn Workspaces.

Curious to hear thoughts and input on this.

This is perhaps an esoteric case, but I recently refactored a set of repos to use lerna, and one of the benefits was that lerna doesn't complain about nested monorepos. Yarn 1 can't do it (and nobody's really working on yarn 1). Yarn 2 is supposed to, but I haven't gotten it to work properly in the way that matches the workflow I need where the nested repo can be pulled out into a completely different repo and still function, lockfiles and all, via git-subrepo.

[goldhand]

I don't mean this in any negative way or to invalidate all the work put into Lerna, but I wonder if Lerna is deprecated/obsolete at this point. There's plenty of material on how to use Lerna with Yarn Workspaces together, but it's not clear what Lerna actually adds that you can't just do with Yarn Workspaces.

Curious to hear thoughts and input on this.

Hey @warent, your question isn't very relevant to this discussion. Yarn workspaces and lerna have both been around for a few years now and there's a lot of discussion around your question available online. My personal response to your question is that I would not use yarn. Npm workspaces is another topic but it's in development and still doesn't address the author's concerns.

[warent]

@goldhand Fair point, my comment was intended to refer to alternative solutions in general, using yarn workspaces as an example. I am interested in those discussions you're referring to if you could point me to any specific ones. I haven't had any luck finding any.

That being said, it is relevant because it directly addresses the author's first question:

What are the longterm options for this package?

My response being: potentially deprecate the package, and encourage migration away from it.