Add scripts to generate DT compatible definition/test files

[ikatyang]

WIP at add-scripts-to-generate-dt-compatible branch.

Progress:

• generated structure should look something like:

  /
    index.d.ts
    src/
      *.d.ts
    ramda-tests.ts (remove failing tests for dts-lint if needed, (optional) combine all unit tests into one file)
    tslint.json (extends: dtslint/dt.json)
    tsconfig.json (files: index.d.ts, ramda-tests.ts, src/*.d.ts)
  

• add a file for listing maintainers information (to generate DT's header, copied from DT first).
• run prettier for generated files first to prevent linting error from dts-lint
• pass the dtslint test ($ExpectType/$ExpectError)
• test tests from DT before making a PR to DT, make sure no regression from DT. (should be another issue)
• [FUTURE] maybe write some scripts to auto make PR to DT?!

[KiaraGrouwstra]

See DefinitelyTyped/DefinitelyTyped#15912, at the time I made the needed adjustments but got stuck on failing tests.

[ikatyang]

I haven't tried the $ExpectError from dtslint, if it can handle failing tests properly then it'd be easy to transform, otherwise I'll remove those failing tests while transforming, thanks for the information. 👍

[ikatyang]

The $ExpectError/Type behaves weird in some cases (travis log).

• $ExpectError does not suppress any error in the generated test cases, but it did suppress errors in my local test repo, how could it happen?!

• $ExpectType works well in most cases

  • but it threw in this case

    // $ExpectType boolean
    R.or(false, true); //=> true
    // $ExpectType 0 | never[]
    R.or(0, []); //=> []
    // $ExpectType number | never[]
    R.or(0)([]); //=> []
    // $ExpectType "" | null
    R.or(null, ""); //=> ''

    with outputs

    ERROR: 1979:5   expect  Expected type to be:
        0 | never[]
    got:
        or_11<0, never[]>
    ERROR: 1981:5   expect  Expected type to be:
        number | never[]
    got:
        or_11<number, never[]>
    ERROR: 1983:5   expect  Expected type to be:
        "" | null
    got:
        or_11<null, "">
    

  • and it did not throw errors with the same kind of test for R.and
    • test cases

      // $ExpectType boolean
      R.and(false, true); //=> false
      // $ExpectType 0 | never[]
      R.and(0, []); //=> 0
      // $ExpectType number | never[]
      R.and(0)([]); //=> 0
      // $ExpectType "" | null
      R.and(null, ""); //=> null

    • R.or and R.and returns the same type (T | U), how weird...

Still finding what the cause is 😭

[KiaraGrouwstra]

That's odd, yeah. Then again, I guess the number of cases where we'd really wanna verify errors is kinda limited, right?
Does it also throw the or_11 thing on the distributions without placeholder?

[ikatyang]

There's only 7 failing tests, but I'd like to keep them alive unless there's no solution.

And I tried dist-simple with the same test cases, got the same result.

---

Interestingly, if I cut them down:

import * as R from "ramda";

// tslint:disable comment-format

// @dts-jest:group and
(() => {
    // $ExpectType boolean
    R.and(false, true); //=> false
    // $ExpectType 0 | never[]
    R.and(0, []); //=> 0
    // $ExpectType number | never[]
    R.and(0)([]); //=> 0
    // $ExpectType "" | null
    R.and(null, ""); //=> null
})();

// @dts-jest:group or
(() => {
    // $ExpectType boolean
    R.or(false, true); //=> true
    // $ExpectType 0 | never[]
    R.or(0, []); //=> []
    // $ExpectType number | never[]
    R.or(0)([]); //=> []
    // $ExpectType "" | null
    R.or(null, ""); //=> ''
})();

The output will become:

ERROR: 10:5  expect  Expected type to be:
  0 | never[]
got:
  and_11<0, never[]>
ERROR: 12:5  expect  Expected type to be:
  number | never[]
got:
  and_11<number, never[]>
ERROR: 14:5  expect  Expected type to be:
  "" | null
got:
  and_11<null, "">
ERROR: 22:5  expect  Expected type to be:
  0 | never[]
got:
  and_11<0, never[]>
ERROR: 24:5  expect  Expected type to be:
  number | never[]
got:
  and_11<number, never[]>
ERROR: 26:5  expect  Expected type to be:
  "" | null
got:
  and_11<null, "">

If I place R.or before R.and, then the output will become errors for R.or.

It seems order matters...

[KiaraGrouwstra]

well, if commenting the error tests would help get us a DT PR in, then whatever I guess.
That order thing is weird, yeah. I knew that could happen with interface overloads, but not with named types...
I guess the other mystery is why the union types won't unwrap though. I wonder if an alternative could be to have the all-1 types could be in-lined so it'd just directly do this:

type and_10<T> = {
    <U>(b: U): T | U;
};

[ikatyang]

I found the reason why union types didn't unwrapped, they did not pass the enclosingDeclaration parameter to typeToString (dtslint vs dts-jest), I'd like to open a PR there but I think they won't accept, haha. It seems I should inline those all-1 types in my dts-element-fp, though it might increase the size of generated files.

[KiaraGrouwstra]

Why not? Try opening an issue with them explaining the problem to get their take on why they passed undefined at least, hopefully for them passing it wouldn't break anything. :)

[ikatyang]

Opened issue microsoft/dtslint#57, hope they would accept the changes.

[treybrisbane]

Is this still happening?

Is there still uncertainty on how to proceed here, or is the path clear and it's just a matter of actually doing it?

[ikatyang]

The infrastructure in this repo is somehow hard to understand, even I as the author sometimes forgot why I wrote some code in that way, I think it's time to rewrite those scripts and also simplify the codegen using some conditional types so that it'd be easier for people to contribute. This PR will be done after it.

[treybrisbane]

Fair enough. :)