I'm glad you brought it up. There are reasons for a lot of this, but I agree that improvements can be made. Also - huge thanks for focusing on the kind of issues that make it easier for others to contribute, that's a great philosophy for contribution.

First of all, I think an obvious win is just to bump up the version of Jest being used to ensure the project is running on the latest. That should help with VSCode and other IDE integration.

Unit tests are written mostly in typescript because it's a two-in-one test, we're also ensuring the type definitions are correct. I recently made a change to the jest runner script to ensure no caching occurs, which ensures that typescript tests get static type checked before runtime tests run.

I think it's important to maintain the tests as typescript when possible, and use plain JS tests only when explicitly testing something outside of the typescript coverage - it ensures we get good coverage.

You may notice some tests actually cast through any in cases where it's testing error behavior, one thing I would like to see improved is something similar to the flow type tests where comments can be inserted where static type check errors are expected. That's been hugely helpful in testing the quality of the flow type tests. Since the jestPreProcessor is programmatically running those type tests, I don't think that would be too difficult to achieve.

For running tests against src/ instead of dist/, that gets tricky. It's dependent on another task #1044 to ensure the type definition files align with the source files. It also depends on a fairly major refactoring to actually ensure the src/ is valid ES2015 code - it was written before ES2015 was finalized and contains many quirks that now wouldn't run as written. There's still a good quality about testing the code you expect to distribute rather than the source code itself (ie. for compiled code, tests run against the compiled binary). One improvement that can be made more immediately is a continuous incremental build and test repl, that way the moment you save a file you have the relevant test results in a few seconds. I know the latest version of Jest added a repl, but some additional work may be necessary to get it integrated with the build step.

@leebyron thanks for explanation! I will dig more tonight.

P.S. GJ with issues! This repo looks so lonely without you.

just to bump up the version of Jest

Done and tested.

Unit tests are written mostly in typescript because it's a two-in-one test, we're also ensuring the type definitions are correct.

Now it's totally makes sense!

I think it's important to maintain the tests as typescript when possible, and use plain JS tests only when explicitly testing something outside of the typescript coverage - it ensures we get good coverage.

We can do something like this:

1. src/internal - test non public code (like internal utils, collections), good for test first development.
2. dist - test public api (basically current approach).

I would like to see improved is something similar to the flow type tests where comments can be inserted where static type check errors are expected.

It's doable, but I will start with typescript first cause I have more experience with it.

to ensure the type definition files align with the source files. It also depends on a fairly major refactoring to actually ensure the src/ is valid ES2015 code

We also can add flow annotations to files (ofcourse start with @flow-weak). But I'm not sure is it's possible to generate *.js.flow files flor *.js (like *.d.ts from *.ts)

Roadmap:

1. Replace custom jest declarations with @types/jest
2. Modernize Typescript tests (maybe use ts-lint)
3. Use eslint in pure js tests.
4. Create flowtype tests from typescript test. Add dtslint tests.

Sorry I think I wasn't very clear on the flow type tests that led to your last action item there.

What I meant was that the existing flow type tests have a // $ExpectError feature that's very useful for test writing and that feature would be a valuable addition to the existing typescript tests.

Does eslint have a typescript compiler plugin? That would be a great way to unify them if possible

What I meant was that the existing flow type tests have a // $ExpectError feature that's very useful for test writing and that feature would be a valuable addition to the existing typescript tests.

Oh, as I said before i'm not good at flow 😅, I'll search for similar behavior in typescript tomorrow.

Does eslint have a typescript compiler plugin? That would be a great way to unify them if possible

There are some solutions - eslint-plugin-typescript, typescript-eslint-parser. Both are very experimental so I never used them.

flow type tests have a // $ExpectError feature that's very useful

Found it - dtslint.

Very cool that looks like just what we need

@umidbekkarimov - happy to see you make progress on this, are you interested in continuing this work, or would you like to find a new owner for this?

@leebyron I'm glad to improve such a great tool 👍

Before starting "Run tests against src directory" I wanted to resolve #1044 and #317.
And relying on your #317 (comment) we had these subtasks.

• Deprecate all methods like toMap() in favor of passing instances to Map() constructors.
• Ensure common methods which return full structures are factored out (groupBy() is a good example) into helper functions instead.
• Find a new build path which allows for a single distribution file independent of node style requires.

But also what I was thinking about is:

1. Build with es classes followed by es specification.
   It will lead to breaking changes such as deprecation of const map = Map() style.
   As workaround we could add helpers like: const map = Map.empty() of const map = Map.from(obj).

2. Factorize most of shared functionality outside of classes.
   Each collection has tons of circular dependencies, so I was thinking what if we will use functional style to resolve this problem, e.g map.keySeq().update(toList).

3. Tree shaking friendly.
   One thought was to remove statics from classes, because uglify js will not mark classes with statics as dead code, but this issue will be resolved in webpack@4 (see add pure modules webpack/webpack#5435).
   So we just need to process files through bable in to es directory. And no more "too much code" issues.

4. Use ES features (Map, Set, WeakMap, Symbol) and require users to polyfill them.

5. Write in typescript or flowtype - so one of type defs will be generated automatically.

I came up with this suggestions when I started working on on this #317.

There a lot of really big breaking changes and it would be pretty hard to write good codemod to cover all style changes, and it will be a pain for long time users (such as myself) to migrate.

I guess resolving these issues will automatically close this "Run tests against src directory". So maybe we need to move this discussions somewhere else.

Yeah that list of things is much broader in scope than modernizing the test runner, though still exciting.

Right now it's important for us to focus on stability to achieve a 4.0 release. I'd like to have as few additional breaking changes for that release so migration is possible.

Currently testing against src is impossible because of circular dependencies, so we have to bundle to single file and run all tests.

I played around with tests, tried to use different jest-preprocessors, but still issue will be on node level.

Good to know.

Testing against dist/ isn't that bad. It's kind of nice that it tests the code that we actually ship to npm.

Thanks to your ts-tests, I was able to simplify the jest harness with #1342 - Travis CI now completes in ~3min instead of ~11min.

Let's consider this particular task done. I think we've simplified, sped up, and improved tests quite a bit with this effort.

Feel free to open new issues for the other goals you mentioned above.