search

jonaskello / tslint-immutable

TSLint rules to disable mutation in TypeScript.
MIT License
417 stars 14 forks source link

Fixes #117 #120

Closed RebeccaStevens closed 5 years ago

RebeccaStevens commented 5 years ago

Fixes #117

codecov[bot] commented 5 years ago

Codecov Report

Merging #120 into master will not change coverage. The diff coverage is 100%.

Impacted file tree graph

@@          Coverage Diff          @@
##           master   #120   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files          16     16           
  Lines         364    370    +6     
  Branches      153    155    +2     
=====================================
+ Hits          364    370    +6
Impacted Files Coverage Δ
src/readonlyArrayRule.ts 100% <100%> (ø) :arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update fac446a...4e44389. Read the comment docs.

jonaskello commented 5 years ago

@RebeccaStevens Nice work as usual :-). Given the amount of good work you have done on this package I would be happy to add you as a collaborator (github+npm) so you can release your changes faster. Let me know if you're interested in that or if I should go ahead and release this PR.

RebeccaStevens commented 5 years ago

Hey @jonaskello,

I'd love to be collaborator on the package. However I've never been a collaborator on someone else's package before so I'm a bit nervous that I'll do something wrong. I'd probably need you to walk me through everything at first to make sure I'm doing it right.

But anyway, yes this PR is ready to be released.

jonaskello commented 5 years ago

Great, I added you to this repo so you should have gotten an invite. Once you have that I think you should be able to merge this PR.

No problem with doing things wrong, there are always ways to fix it :-). I think you will be able to figure it out and if you have any questions just make an issue and ask. I'll outline some steps below to get you started.

So what I usually do after a PR is merged:

  1. Update the changelog under the heading "unreleased" with a short description and links to issue and PR if releveant. For the changelog format I try to follow some simple rules from keep a changelog. It would actually be better if the changelog additions were part of each PR but I haven't gotten around to nagging contributors about that, but feel free to add changelog entries to this PR :-).

Then when I want to release a new version (which is usually right after merging a PR, but sometimes I collect several changes):

  1. Figure out the new version number for the release. I try to follow semver as far as possible.
  2. Create a new heading in the changelog with the new version number, taking care to update the comparision links at the bottom.
  3. Move stuff from the "unreleased" section to the new heading with the new version number.
  4. Commit and push the above.
  5. Run the appropriate publish script which will automatically increment the version in package.json and publish to npm.
  6. Done :-)
jonaskello commented 5 years ago

@RebeccaStevens Btw, I also need your npm username in order to give you access to publishing. Is it the same as your github username?

RebeccaStevens commented 5 years ago

@jonaskello I'll try not to let you down. My npm username is: rebeccastevens

Just a quick question on future PRs I make, should I continue making them on my fork or should I just make a new branch on here for them?

jonaskello commented 5 years ago

Well, I don't have a preference for that. I guess making branches directly in this repo might be more convenient for you and that is totally OK with me.

I think I have managed to add you as github and npm collaborator now so you can go ahead and merge and release this if you want. Let me know if you need any help :-).