Is it going to be maintained?

[murbanowicz]

@NagRock are you going to maintain this library?
There will be soon a year since last PR has been merged.
There is 20 open PRs at this moment.
If you don't have the time, maybe it would be good to allow others to also maintain this library?

[cspotcode]

@murbanowicz How about we start off creating a fork, with the goal of eventually merging our changes back here if/when we're able to get maintainership access?

We can open a pull request from our fork's main branch and track a list of the issues / PRs that it addresses.

[cspotcode]

@murbanowicz I've set up a fork repo with tests running: https://github.com/cspotcode/ts-mockito

There's a PR to upgrade dependencies. Getting the tests passing should be our first order of business I think.

[gCardinal]

There's also this fork where someone has been trying to bring PRs back from this repository to his: https://www.npmjs.com/package/@johanblumenberg/ts-mockito

[mikeporterdev]

@johanblumenberg 's fork seems to have new additional features (some of which are excellent additions) but is out of date with the master branch of the main repo and is not in line with 2.x. This would make it awkward for us to swap to until it's updated

[cspotcode]

@mikeporterdev I think this means we should be helping to merge any missing features of this repo into that fork, so that we have a single version we can use going forward.

[NagRock]

Hi all. Big sorry for late replay.
Yes I got not too much time to maintain library and started thinking of giving access to some other people. I will take a look into PR's that looks good and try to contact authors if they would like to take some part of responsibility about reviewing and merging PRs.
Yesterday I've bumped dependencies and merged few PRs. I will try to review some more today but as I cannot do that regular the only option I see is more contributors with write / release access.

[johanblumenberg]

Please let me know if there is anything I can do to contribute

[mikeporterdev]

@NagRock Any update? It seems with @johanblumenberg and @cspotcode we have two folks who are ready and able as contributors.

[cspotcode]

@NagRock how about we create a few criteria for potential contributors? For example, @johanblumenberg has already created a fork, merged useful features and, and published the results, so they're a shoe-in. By contrast, I've offered to help but haven't done any work, so you have less confidence I can be a good maintainer.

Do these criteria seem acceptable? Will this help get the project moving without causing undue fear that granting GH and npm access to additional contributors will hurt the project? I feel that tends to be a source of hesitation on many projects.

[cspotcode]

Adding to my previous comments, someone like me -- offered to help but has not done anything yet -- can be asked to work on a few PRs first, then they can be made a contributor if that goes well.

[guyca]

@NagRock This library has been a life-saver for us. A lot of people would appreciate it if you gave access to someone so the project can continue. You've done amazing work and we understand priorities change.

[mikeporterdev]

@cspotcode In the meantime, if there's anything folks can do to help push forward your fork please let us know

[cspotcode]

@mikeporterdev first order of business is to make the tests pass here: TypeStrong#2

Anyone who wants to work on that is free to make their own branch and PR from mine, and we'll be sure to get CI running so you get feedback.

[cspotcode]

@LironHazan has jumped in on cspotcode#2 and got the tests passing. (very quickly, I might add!)

They have also started discussion in cspotcode#3 about future enhancements.

Can someone on this thread please volunteer to look at the pull requests in this repo (NagRock) and post a triaged list in cspotcode#3? Or, even better, port some pull requests directly to the cspotcode repo.

[cspotcode]

It's been a couple weeks, so now we have to be honest with ourselves: when people asked if there was anything they could do to help the fork, did they mean it? Or were they hoping for others to do the work? It's ok to be honest either way. Let us know.

[LironHazan]

@cspotcode I would be defiantly happier if this project was properly maintained so I think you're doing an important work with gathering this thread and I hope the fixes would eventually be merged to this repo.. meanwhile I left a question in cspotcode#3

[Markus-Ende]

Hi all, I'm really glad that this discussion was started. We from @qupaya also rely heavily on this library and promote it in every Angular/TypeScript project we are consulting. Would be a shame if this wasn't maintained anymore (no offense @NagRock, of course. I can totally understand that priorities shift. Thank you for your time and effort that went into this awesome library!).

I already contributed to ts-mockito and also wrote a little wrapper for it for Angular projects. Don't know if this is an option for @NagRock and you all, but @qupaya could also help with maintaining.

[cspotcode]

How about we plan to publish a release on Friday? We have a handful of PRs that require approval. I'm swamped with my paycheck job this week; is anyone able to offer reviews of these pull requests? https://github.com/cspotcode/ts-mockito/pulls

@LironHazan has permission to merge them without me, and I can set aside time to publish to npm on Friday.

It looks like release notes / changelog entries have traditionally been handled as Github Releases, so we can keep doing that for the fork. (for example: https://github.com/NagRock/ts-mockito/releases)

I've created TypeStrong#9 to document how we publish and collaborate; suggestions welcome.

[LironHazan]

Hey @Markus-Ende! likewise, I recently encouraged my team to start using ts-mockito in Angular as it really shines when having components/services with dependencies needed to be mocked.
I created following cli tool which enables generating test templates from components/services or any "class" based with ts-mockito in use (I used ts-morph, not schematics, its agnostic to frameworks), maybe it could be useful for you as well :)

[Markus-Ende]

How about we plan to publish a release on Friday? We have a handful of PRs that require approval. I'm swamped with my paycheck job this week; is anyone able to offer reviews of these pull requests? https://github.com/cspotcode/ts-mockito/pulls

@LironHazan has permission to merge them without me, and I can set aside time to publish to npm on Friday.

It looks like release notes / changelog entries have traditionally been handled as Github Releases, so we can keep doing that for the fork. (for example: https://github.com/NagRock/ts-mockito/releases)

I've created cspotcode#9 to document how we publish and collaborate; suggestions welcome.

like @LironHazan I would also prefer if we could get this project properly maintained instead of creating forks. We now have already two: https://github.com/cspotcode/ts-mockito and https://www.npmjs.com/package/@johanblumenberg/ts-mockito. In my opinion, the goal must be to concentrate in one place.

But of course, this won't work without @NagRock. We really need feedback from you, @NagRock, if you really intend to open this repository for more maintainers.

[cspotcode]

The way I see it, we're already doing the maintenance you desire.

Github won't allow us to push here so we push to a difference repo.
npm won't let us publish to ts-mockito so we publish to a different name.

Both are temporary technicalities.

As far as getting PRs reviewed and merged, that is already happening.

The goal has always been for our maintenance work to be eventually published to npm as ts-mockito. In the meantime, we're not sitting around; I'm actually making it happen. You will have a version with new features that you can actually install and use. That's the goal.

Before asking NagRock if they intend to open this repository for more maintainers, we should show we're willing to do the work, instead of mere lip service.

[Markus-Ende]

Besides having not too much time, @NagRock maybe had other reasons why he chose not to merge PRs like fnmock into this library (coding style, naming, etc.). We already have a fork from @johanblumenberg including his PRs. I don't see how another fork that merges the same PRs will change @NagRock|s reasoning.

So, in my opinion, if the goal is to get changes into this repository, we need a clear statement from @NagRock, before adding new features.

@NagRock how high is the probability, that you'll merge back changes into this repository from a fork?

[LironHazan]

@Markus-Ende I hope @NagRock will reply, a proper open source project nowadays which obviously used by many users should have well defined coding style documented at the repo itself and an enforcement of it by eslint + prettier configurations including an instruction of how to auto-detect those files via the "seasonal" contributor IDE..

At this scale of use I don't think it should be a one man decision what to merge/reject, I respect the awesome work @NagRock did with this lib but if it won't be continuously maintained I wouldn't be able to use it, there's an element of "trust" knowing that bugs would be addressed by a community and "passed" vulnerabilities would also be taken in consideration, I assume you feel the same as a member of an organization, questioning each other makes us build better software, there's a lot of place for a level-up here.

I firstly thought the best scenario is to accept changes into this repo, but I feel we can't expect that to happen by @NagRock and it's legit, he stated that he doesn't have time for actively maintaining it, proprieties were changed..
Having said that, I think what @cspotcode tries to do is the closest act for maintaining the project by a community, I more relate to having it under TypeStrong rather as a personal unmaintained repo, I'm still not 100% sure who would be accepting/approving PR's in that case?

[fgblomqvist]

@NagRock any update on this? You've done some great work on this project but it would be very unfortunate if you just let it die rather than pass the torch along to some other people (especially since there are people willing to take it) 😕

[pauleustice]

@NagRock Is there anything we can do to help? ts-mockito no longer seems to work with Angular 14 but I'm not familiar enough with the code to work out what's going wrong. Would love to be able to contribute somehow to help get this incredibly useful library up-to-date and usable again!

[LironHazan]

@pauleustice Hey,
What's stopped working for you when upgraded to Angular 14?
We have a huge Angular repo which was recently upgraded to version 14 and the existing tests which use tsmockito are running fine, if you'll share the error I could ask my team mate if he faced the same issue and how he resolved it.

BTW I've written a CLI which will generate the specs for you based on your classes/utils files with mocks, it could spare some time --> https://www.npmjs.com/package/qutilz

[pauleustice]

@LironHazan Oh thanks, any help would be appreciated! I've just established that it wasn't Angular in particular, but was actually Typescript 4.4.2 and above.

I created a test repo with a bunch of spec files that highlight the issue. If you'd like to take a look, it's here.

I imagine this must be affecting more people than just my team!

Your CLI library looks useful, have you thought about making it into an Nx schematic? I don't tend to work on Typescript projects these days, but I'll mention it to some colleagues!

[LironHazan]

@pauleustice I just replied on the other thread :)
Thanks for the repo! I would try to check it after I'll upgrade the typescript version of the fork,
Regarding Nx schematics, that could be a cool idea actually, having a bridge between the plugin API to my lib and publish a community plugin..

[cspotcode]

@typestrong/ts-mockito has been published.

https://www.npmjs.com/package/@typestrong/ts-mockito

Pull requests can go here:
https://github.com/typestrong/ts-mockito

[johanblumenberg]

I created a test repo with a bunch of spec files that highlight the issue. If you'd like to take a look, it's here.

I created a PR here to describe what the problem is, and a possible solution: TypeStrong#17

[latobibor]

Did anyone try reaching @NagRock through his LinkedIn? Checking github notifications is really a hit-or-miss thing.

[pauleustice]

Not personally. While I'm thankful for all the efforts on the original project, and especially to @LironHazan and @johanblumenberg in fixing up the fork with some great collaboration last year, our team have decided to move away from ts-mockito entirely. The pain caused with the Typescript update last year was far too much of a burden to want to repeat, especially in an enterprise scenario.

In fact, as a result of all that, we ended up introducing new processes (both automated and manual) to ensure we don't get bitten by consuming poorly maintained packages in future. One thing I'd really recommend is detecting and flagging when new dependencies are added in PRs; ours links off to the Snyk npm package advisor which gives ratings on things like maintenance frequency and such.

For example, here's ts-mockito's entry.

For anyone using Angular, I can highly recommend ng-mocks instead