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

Please add typescript typings :) #24

Open
kristianmandrup opened this issue Feb 4, 2019 · 7 comments
Open

Please add typescript typings :) #24

kristianmandrup opened this issue Feb 4, 2019 · 7 comments

Comments

@kristianmandrup
Copy link

kristianmandrup commented Feb 4, 2019

Can be auto generated via tsconfig setting I believe :)

https://stackoverflow.com/questions/12687779/how-do-you-produce-a-d-ts-typings-definition-file-from-an-existing-javascript

npm install -g dts-gen
dts-gen -m <your-module>
@kristianmandrup
Copy link
Author

Generated patchinko.d.ts file ;) via dts

/** Declaration file generated by dts-gen */

export function D(): void;

export function P(target: any, ...args: any[]): any;

export function PS(target: any, input: any, ...args: any[]): any;

export function S(closure: any): any;

export function constant(a: any, b: any, ...args: any[]): any;

export function immutable(a: any, b: any, ...args: any[]): any;

export namespace D {
    const prototype: {
    };

}

export namespace P {
    const prototype: {
    };

}

export namespace PS {
    const prototype: {
    };

}

export namespace S {
    const prototype: {
    };

}

export namespace constant {
    const prototype: {
    };

}

export namespace immutable {
    const prototype: {
    };

}

@barneycarroll
Copy link
Owner

Thanks @kristianmandrup! Sorry for my absence. I'll see about getting this integrated.

@jsamr
Copy link

jsamr commented Mar 15, 2019

@barneycarroll @kristianmandrup I have written more complete types with deep inference for my project. However, I have just tested with Typescript 3.1. If those fail for older versions, we could use your as default, and version redirect for mine.

@jsamr
Copy link

jsamr commented Mar 15, 2019

Here they are. You'll notice the spec files, where all the correct and incorrect examples from readme file are handled appropriately.
image

EDIT
PS1: We could use typings-checker for those specs
PS2: I would be OK to make a PR about it

@kristianmandrup
Copy link
Author

Great! Well done :)

@barneycarroll
Copy link
Owner

@jsamr that would be great, thanks! I'd be very pleased to accept a PR on this.

jsamr added a commit to jsamr/patchinko that referenced this issue Feb 17, 2020
resolves barneycarroll#24

Tested and linted typescript definitions for TS ⩾ 3.5.
Run tests with `npm run test:ts` which uses dtslint in the background.

The root of typings are in types/patchinko, a requirement from dtslint.
The most important tests are located in __tests__/explicit and
__tests__/overlaoded.

One big feature of those typings is to strictly enforce patchinko
rules. As such, every do and don't from the readme has been carefuly
tested and implemented.

Dtslint does the following:

- Lint the sources according to DefinitelyTyped guidelines;
- Run any test file and check for $ExpectType and $ExpectError
  instructions, report compilation errors;
- Run one batch of test for each TypeScript supported version.
jsamr added a commit to jsamr/patchinko that referenced this issue Feb 17, 2020
resolves barneycarroll#24

Tested and linted typescript definitions for TS ⩾ 3.5.
Run tests with `npm run test:ts` which uses dtslint in the background.

The root of typings are in types/patchinko, a requirement from dtslint.
The most important tests are located in __tests__/explicit and
__tests__/overlaoded.

One big feature of those typings is to strictly enforce patchinko
rules. As such, every do and don't from the readme has been carefuly
tested and implemented.

One limitation of those types however, is that the returned type of a
P(target, ...) call will always be typeof target. Although it could be
 possible, in theory, to find the resulting type from operations such
as deletions ore scoped replacements, I have found this incredibly
difficult and wasn't certain the compiler could follow this level of
complexity and computational burden. Therefore, I thought it would be
an acceptable compromise to return the target type, given the vast
majority of use-cases where one want such outcome.

On the test side, dtslint does the following:

- Lint the sources according to DefinitelyTyped guidelines;
- Run any test file and check for $ExpectType and $ExpectError
  instructions, report compilation errors;
- Run one batch of test for each TypeScript supported version.
jsamr added a commit to jsamr/patchinko that referenced this issue Feb 17, 2020
resolves barneycarroll#24

Tested and linted typescript definitions for TS ⩾ 3.5.
Run tests with `npm run test:ts` which uses dtslint in the background.

The root of typings are in types/patchinko, a requirement from dtslint.
The most important tests are located in __tests__/explicit and
__tests__/overlaoded.

One big feature of those typings is to strictly enforce patchinko
rules. As such, every do and don't from the readme has been carefuly
tested and implemented.

One limitation of those types however, is that the returned type of a
P(target, ...) call will always be typeof target. Although it could be
 possible, in theory, to find the resulting type from operations such
as deletions ore scoped replacements, I have found this incredibly
difficult and wasn't certain the compiler could follow this level of
complexity and computational burden. Therefore, I thought it would be
an acceptable compromise to return the target type, given the vast
majority of use-cases where one want such outcome.

On the test side, dtslint does the following:

- Lint the sources according to DefinitelyTyped guidelines;
- Run any test file and check for $ExpectType and $ExpectError
  instructions, report compilation errors;
- Run one batch of test for each TypeScript supported version.
jsamr added a commit to jsamr/patchinko that referenced this issue Feb 18, 2020
resolves barneycarroll#24

Tested and linted typescript definitions for TS ⩾ 3.5.
Run tests with `npm run test:ts` which uses dtslint in the background.

The root of typings are in types/patchinko, a requirement from dtslint.
The most important tests are located in __tests__/explicit and
__tests__/overlaoded.

One big feature of those typings is to strictly enforce patchinko
rules. As such, every do and don't from the readme has been carefuly
tested and implemented.

One limitation of those types however, is that the returned type of a
P(target, ...) call will always be typeof target. Although it could be
 possible, in theory, to find the resulting type from operations such
as deletions ore scoped replacements, I have found this incredibly
difficult and wasn't certain the compiler could follow this level of
complexity and computational burden. Therefore, I thought it would be
an acceptable compromise to return the target type, given the vast
majority of use-cases where one want such outcome.

On the test side, dtslint does the following:

- Lint the sources according to DefinitelyTyped guidelines;
- Run any test file and check for $ExpectType and $ExpectError
  instructions, report compilation errors;
- Run one batch of test for each TypeScript supported version.
@jsamr
Copy link

jsamr commented Feb 18, 2020

@kristianmandrup @barneycarroll

So, I took some time to rework this, stumbling on some errors of the draft I proposed. But the final outcome is, so far, very satisfying: #32. It would very appreciated if you took a look, and help with the review. You can start by taking a look at the types/patchinko/__tests__ folder and make sure they accurately follow patchinko API somehow complex rules.

Just git clone https://github.com/jsamr/patchinko.git and git checkout ts. If you want to test the types in your project (TS ⩾ 3.5), change patchinko version in your package.json as follow:

{
  "dependencies": {
    "patchinko": "github:jsamr/patchinko#ts"
  }
}

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 a pull request may close this issue.

3 participants