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.

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.

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.

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.

@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.

@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.

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)

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

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.

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.

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.

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.

@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.

I see @warent, the first reason I mention is that I would strongly discourage using yarn for package management if I was reviewing a project design. There are a lot of reasons but this article from 2018 can explain most. Without getting into a debate over yarn vs npm, we can at least assume "use yarn instead" is not a viable option for many developers who, like me, want to use npm with our monorepos.

Second, yarn does not replace all that lerna is doing as explained in this article about lerna + yarn.

This venn diagram is helpful for clarifying:

I also want to mention I really don't like to say a comment is not relevant and I def don't want to sound rude, I just really feel like this discussion should be focused on some of the other points and am very concerned about the state of lerna. I do agree that offering an alternative to lerna is an option. I recommend that as fall back, incase other options fail. In this comment, I recommend npm workspaces migration plan as the 3rd option after 1 and 2 fail.

@MikeActually has there been any more movement on this since September? Has the situation changed or improved, or is there a plan in place?

@rikoe I would love to know too. Such a great tool!

@rikoe and @jsefiani - I don't have anything to share, while I was given permission to merge PRs, I would not be able to push updates to npm. My suggestion would be to explore the options that offer a semi related solution, and see if one of them fit your needs. If you absolutely need Lerna, forking it might be your best bet. The other option is to start moving the project forward, so, creating small PRs to help move the project forward. From what I can tell, PRs are not even passing automation checks, so doing research as to why the API response codes from npm changed, and what the best solution to address those failed test scenarios would be one thing to take on. I recall someone indicating that there are other obstacles in the automation. I don't think any PRs can really move forward until that happens.

There is also a Slack that was created via #2715 .

Candidly, it's tough to do anything with this project without a central longterm owner, and it seems like the historical owners have little interest in the project at this point.

I will say that it looks like @evocateur made a number of commits in early november - he is the best person to speak to the status of the project - https://github.com/lerna/lerna/commits?author=evocateur&since=2020-11-01&until=2020-12-01

For a few reasons, this issue among them, we explored other options.

We've migrated to Atlassian's Changesets (https://github.com/atlassian/changesets), which is an evolution of Atlassian's experiments with Lerna and semantic-release (https://github.com/atlassian/lerna-semantic-release).

It is great, we now have a Dependabot-like publishing flow that's a lot more automated. Also, it doesn't regularly crash out due to git tag mismatches or attempting to publish things to npm that are already there.

I can recommend it as a clean, hassle-free replacement for Lerna.

I should write a proper resignation post, but burnout. I've been farting around in the next branch because it soothes me, oddly. I'd prefer to write a completely separate tool to handle the important bits of Lerna (version + publish) rather than trudge along with my own foibles manifested in code.

anyway, just wanted to say i appreciate all the effort in this thread. i'm sorry i'm not better at it.

I'd prefer to write a completely separate tool to handle the important bits of Lerna ...

Breaking Lerna apart (run, list, version, publish...). Maybe it would help with the maintenance cost?

Hello @inca, here at KOJI we are heavily using Lerna for our monorepo management. We don't want to migrate on other available solution that sound heavy or too far from basic NPM usage. We are willing to take on the maintenance with our developers and the responsibility to merge Pull Request

@icrotz and others who offer to maintain this project:

You are free to fork and maintain this wherever and however you want.

You don’t need any approval for that and it carries no risk for the current maintainers.

Adding maintainers to a widely used project is not something to be taken lightly by existing maintainers. History has shown that such a thing is vulnerable to social engineering attacks.

@icrotz Fork and publish as @kerna/ or some similar variation?

New fork has been created: https://github.com/KOJI-SAS/kerna
I will publish the new application on NPM in some time. Don't hesitate to ask to become contributors on it.

Is there any alternative that can controll the version of monorepo?

fyi: #3121

Nrwl is taking over stewardship of Lerna

Lerna is dead... Long live Lerna!!! 😄 Thanks for Nrwl for taking the torch #3121

On a side note, I just released Lerna-Lite version 1.2.0 which brings support for yarn/pnpm workspace: protocol. No need for alternatives anymore when you can use Lerna/Lerna-Lite 😉

Give it a try and happy coding 🎉

Hi Folks 👋

You may or may not know that lerna is now under the stewardship of Nrwl (announcement here #3121), a company with a long history of not just producing valuable open-source software (OSS), but also backing others (at the time of writing, Nrwl has donated over $50,000 to OSS it hasn't created, see https://opencollective.com/nx for full details).

Quite simply, Nrwl ❤️ OSS, and is committed to making lerna the best it can be. We use it ourselves.

We hope you will continue to be a part of this community as we look to take things forward from here!

Please see #3140 for more details on our plans for 2022.