Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: improve typing of flatten to infer return iterator type #22

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

forivall
Copy link
Contributor

@forivall forivall commented Oct 3, 2018

Also add a test for flatten, based on flatten.test.ts

Also add a test for flatten, based on flatten.test.ts
@codecov
Copy link

codecov bot commented Oct 3, 2018

Codecov Report

Merging #22 into master will increase coverage by 1.22%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #22      +/-   ##
==========================================
+ Coverage   92.02%   93.25%   +1.22%     
==========================================
  Files           8        8              
  Lines         163      163              
  Branches       29       29              
==========================================
+ Hits          150      152       +2     
+ Misses         13       11       -2
Impacted Files Coverage Δ
src/iterate.ts 89.36% <100%> (+2.12%) ⬆️

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 8e87efc...271c059. Read the comment docs.

@@ -30,6 +30,18 @@ describe('IteratorWithOperators', () => {
assert.equal(iterator.next().done, true)
})
})
describe('flatten', () => {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test seems to be the exact same as in flatten.test.ts, so I don't understand the purpose? All the other tests in this file do not have tests in external files because they are implemented on the instance itself instead of external classes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main point for myself was to make sure that the type inference matches appropriately. Otherwise, it's just a smoke test that improves coverage. Perhaps it would be best to define the tests in a way to use them in both calling contexts.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. Let's leave this out for now to not duplicate code. Type inference should be tested with https://github.com/Microsoft/dtslint but I don't have that set up yet.
In the future I would see this library use functions like RxJS instead of prototype methods so that would eliminate the coverage concerns.

@cojack
Copy link

cojack commented Mar 17, 2020

@felixfbecker is this PR waiting for something else?

@felixfbecker
Copy link
Owner

@cojack please read the discussion above.

@forivall
Copy link
Contributor Author

@cojack thanks for the reminder! i forgot i had this one open. I'll get to it soon, and I can also set up dtslint or https://www.npmjs.com/package/tsd in a new PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants