-
Notifications
You must be signed in to change notification settings - Fork 5
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
Comments
Generated /** 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: {
};
} |
Thanks @kristianmandrup! Sorry for my absence. I'll see about getting this integrated. |
@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. |
Here they are. You'll notice the spec files, where all the correct and incorrect examples from readme file are handled appropriately. EDIT |
Great! Well done :) |
@jsamr that would be great, thanks! I'd be very pleased to accept a PR on this. |
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.
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.
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.
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.
@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 Just {
"dependencies": {
"patchinko": "github:jsamr/patchinko#ts"
}
} |
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
The text was updated successfully, but these errors were encountered: