Andrew Bradley

@LironHazan where do you want to publish in the short-term? Ideally, we publish to npm `ts-mockito` if and when NagRock grants us access. Until then, should we publish to: *...

I did some more googling and finally found what I was looking for. https://docs.npmjs.com/managing-team-access-to-organization-packages npm will let us create multiple teams inside an organization, each with access to their own...

I did not receive a response from npm for my initial support request; I've sent another. I've included a copy below. If you would prefer to move ahead publishing to...

I would avoid making any changes that are likely to cause merge conflicts with code or pull requests already written for either of the other 2 ts-mockito repositories. Better to...

How do you want to handle changelogs? I don't have a strong opinion. For ts-node we use Github Releases, ([example](https://github.com/TypeStrong/ts-node/releases/tag/v10.2.0)) and I've recently started adding issues and pull requests to...

Let's use Github Releases since NagRock already does: https://github.com/NagRock/ts-mockito/releases The big things that I *personally* try to avoid are: - automatically generating changelogs from commit logs. This requires commit logs...

I created #11 which renames from @cspotcode to @ts-mockito so that we can publish to npm. I also created #12 where we should audit every upstream commit that does not...

It took a little while, but npm transferred the @typestrong scope to me. I'm on vacation this weekend, but I can publish an initial release of @typestrong/ts-mockito when I'm back.

@LironHazan go for it. I won't have much time for ts-mockito so I probably won't be able to do code review, so I say go for it with whatever you...

This might be two bugs in one issue, and sorry the issue title isn't more descriptive, I wasn't entirely sure how to describe this behaviour.