Produce JSX Typings file

[LukeSheard]

There have been questions and issues raised about our typescript definition files (#592 , #596, #609, #681) as well as questions on Slack.

We should refactor our definition files to include a globals.d.ts which should be internal to Inferno, and then also have namespace and module definitions for each Inferno module. We can then wrap these up in a inferno.d.ts typings file which we export with inferno as a package.

This is probably going to mean writing wrapper scripts and automating more build steps which can be included in #685.

[prabhjots]

The whole JXS experience inside typescript could be improved by providing better type definitions as explained here
https://www.typescriptlang.org/docs/handbook/jsx.html

We need to add the following to the inferno.d.ts file

declare module 'inferno' {
	.... // some other stuff 

	global {
            export namespace JSX {
                 interface ElementAttributesProperty {
                     props; // specify the property name to use
                 }
           }
	}
}

Also it would be a good idea to provide a different d.ts file for strongly typing the standard dom components.
Please have a look at this gist for a starting point
https://gist.github.com/prabhjots/271be2d9df5f2880ea5ec73e80fdbf00

[SimonMeskens]

I think the JSX namespace also needs this:

export namespace JSX {
   type Element = VNode;
            
   interface IntrinsicElements {
      ...
   }

This will type the return type of elem() correctly I think.

[pspeter3]

@LukeSheard I'd be happy to help with this if possible.

[Havunen]

What still needs to be done regarding this task?

[Aleksion]

I don't know if it's me doing something wrong, but I hit a few issues when trying to use the Inferno typings in an isomorphic project.

The issue is that the typings assume the importing inferno-component and/or inferno-create-element result in an object with a default export.

However, when typescript is used with module:commonjs, the node version of those components are used and they do NOT contain a default export resulting in the following error:

class Test extends inferno_component_1.default {
                                      ^

TypeError: Class extends value undefined is not a constructor or null

The easy way to ignore this, would be to simply do: const Component = require("inferno-component"), however, typescript doesn't allow extending classes with objects of type "any".

It seems the current typings simply doesn't work with module "commonjs", which is a requirement for running it properly on a server.

Unless I'm missing something?

[Havunen]

@Aleksion is this 1.3.0.-rc.10 or 1.2.2? If it is 1.3 try commenting out "jsnext:main" in all installed inferno package.json's

[Aleksion]

@Havunen - I was using 1.3.0-rc.10
Commenting out jsnext:main did nothing to alleviate the issue. However, running 1.2.2 does work.

The problems I have with that though is that the interfaces are defined Globally - meaning Props clash with my own Props interfaces. I do see why they are, when you worked under the constraints of a single typings file. But it's naturally much less of a problem than it not working at all.

could the reason for it working in 1.2.2 be that you're doing the following in the component files:

module.exports = require('inferno/dist/inferno-component.node');
module.exports.default = module.exports;

thus making sure that whether it's resolved by commonjs or es2015 module loaders, it will always get the right code (rather than relying it the babel, typescript, webpack, node implementation loading the right one)

[Havunen]

ping @longlho any idea regarding this?

[longlho]

yeah it seems like rollup UMD packaging by itself is not enough to satisfy all the use cases. rollup isn't particularly forgiving to non-ES6 modules so we might have to bring back the wrapper file

[thomas-jeepe]

Any updates on typescript jsx support?

[longlho]

Sorry I have not got time to work on this

…

On Mon, Jun 12, 2017 at 8:29 PM thomas-jeepe ***@***.***> wrote: Any updates on typescript jsx support? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#686 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMGbw6xanx0czJtKaOnQmYFIpmp_Zcjks5sDdgGgaJpZM4LdtL0> .

[abirmingham]

Is there any workaround for type-checking TSX element properties in the meantime? See #1121. Losing type-checking on a slice of the code-base is pretty painful.

[deamme]

Please look at this one by @rendall https://gist.github.com/rendall/cdd23c962c88fac3dbd9322cc2b09d58

[rendall]

Would anyone like to form or participate in a working group to hammer this out? If so, please let me know here or direct message. The gist that @deamme referenced above works to resolve basic Inferno TSX conflicts, but conflict with supplemental libraries like inferno-router remain.

[SimonMeskens]

I'd be willing to help with typings. I don't have a lot of time, but I have a lot of knowledge about TypeScript if that helps.

[LukeSheard]

Happy to take a PR for the JSX. I think we can easily integrate it into our existing build process for the type definitions.

[Havunen]

V5 is released. This is fixed there