Typescript source/definitions issues

[nmocruz]

Hi,

I was trying to include this library in a typescript project, but maybe I'm missing something in my tsconfig.json because it starts to check source code in this module inside node_modules even excluding "node_modules". maybe is a noobie question about typescript, or it can be done something to improve here, because it tries to check ts files under node_modules/@profiscience/knockout-contrib-* using my tsconfig.json.

I'm using webpack and awesome-typescript-loader, maybe is required to do something here?

[caseyWebb]

tl;dr: Add esnext.asynciterable to the lib in your tsconfig, and enable allowSyntheticDefaultImports.

Please don't close this issue. I'll do it when this is added to the documentation. I want to double check everything first before sticking it in there though.

---

Explanation:

So, in an ideal world, when publishing a library, you build definition files (.d.ts), and then when consumers of that library use it with tsc, it will use those to type-check their code.

I've tried to get these working in the past, but faced issues.

The first is that in order to use definitions, the types property in the package.json files for individual packages must be pointed to the built definitions. Because this is a monorepo, it leads to the problem where you have to build packages in such an order that packages that are depended on by other packages are built prior to the packages that depend on them, so that those definitions are built.

The second, even more glaring issue, is that tsc blows up when you try to build definitions for mixins, for whatever reason.

Because of this, the types property is pointed to the source code. This means, that in order for it to type check your code that is consuming this library, it must be able to parse this library. Because of certain features used (async generators, e.g. async function* myFunc() {}), you've got to tell tsc that the necessary runtime features exist.

The first issue looks like it's been resolved with TS 3.0.0, although I'm not sure how the build performance will compare; if the second issue isn't resolved though it won't really matter anyway.

[nmocruz]

Ok, make sense. I think that I tried but there's more conflicts, one is related with Jsx other is a missmatch in a type due an init function. I think that maybe we need a new approach to publish only type definitions. Like declare somewhere this list of packages and their dependencies and peek free or resolved ones first.

[nmocruz]

I forked and tried to use the typescript compile API to solve that, it still needs some work.
I'm able to generate d.ts files but I need to run ts-node excluding this d.ts as input files so they can be overwritten.
Then is needed to update packages.jon to point to index.d.ts not to index.ts

[caseyWebb]

@nmocruz I'd definitely prefer to only publish type definitions, I just haven't been able to do it successfully without making the build take a loooooong time. I'm hoping project compilation w/ TS 3.0.0 will fix this.

[nmocruz]

Process all that packages will take some time, looking the Compiler API there's something related with incremental build, not sure if will speed up or not individual packages significantly.

[caseyWebb]

@nmocruz I'm under the impression this is all working? Can you review this documentation to confirm that it covers everything?

[nmocruz]

@caseyWebb I thought everything was sorted but it's the I had the transpileOnly mode actived and was hiding some errors, related with typescript. I really recommend to get a way to pusblish .d.ts files so they don't conflict with ts on the package consumer.
I tried to see the problem and a found maybe what was the bug that make your compilation fail with declaration: true. I belive that TS4094, microsoft/TypeScript#17293 I found a few and seems like is not fixed on TS 3.0.0 and if they move again as they as doing since version 2.4.1, it not be fixed soon.
I found a way to solve only private member, but it not elegant. For protected member only way is make them public or don't reuse super class implementantions.

class a {
   addItem: ()=> void;
   constructor(){
      let privateFunc = ()=>{  console.log("")  };
      this.addItem = () => {
           privateFunc();
      }
  }
}

as a said is not elegant, and we dont know if the TS4094 stuff will be fixed soon.