Better JSDoc types #231

nettybun · 2020-07-14T19:16:39Z

I work almost exclusively in Typescript and not having type support is a show stopper for what is otherwise a lovely project. I looked at #208 and while I think it has good intentions the types are vague. That's not the PR author's fault - tsc just extracts the types from JSDoc. The JSDoc typings could be better.

I went through and tried to fix it up. I removed all the instances of object and function with their real types. There are a few errors and maybe you can correct me on some assumptions I had to make about what is a possible data type but I think these are good types - specifically the use of Middleware as a type to explain that a function is middleware (or returns middleware in the case of rulesheet()).

I arbitrarily picked Middleware.js to write the JSDoc @typedef but they could be anywhere - maybe index.js would be a better place?

I'll leave comments in the PR code to explain what I'm trying to do

src/Parser.js

src/Tokenizer.js

nettybun · 2020-07-14T19:18:10Z

src/Tokenizer.js

- * @return {any}
+ * @typedef {any} T
+ * @param {T} value
+ * @return {T}


I'm trying to show that what you give it is what you get back, as T

this could use @template T

after a thought - while this works OK with @template it doesn't quite showcase how this function should be used and it is specific to this library and its context. It should always be used together with alloc and I feel that both alloc and dealloc should share the same return type. In this case I would keep using the @template but the accepted and returned types should be T[] instead of plain T, because we always allocate and deallocate arrays.

I think that's a limitation of the way the code is written - If this package had any documentation it'd be good for it to go in there. I agree that it's confusing, but I think a lot of this codebase is. A lot of functions have side effects on shared global data, or are aliases to other functions, or change data types randomly in order to have "terse" code. It feels like there's too much to fix in terms of type safety.

I'm making another comment in this thread in a sec, basically saying I'd be happy for you to take over since I imagine this PR will stall.

src/Utility.js

src/Parser.js

coveralls · 2020-07-14T20:51:48Z

Pull Request Test Coverage Report for Build 27c44ce386aa07c6c2785babfb86216bf855799f-PR-231

0 of 0 changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals
Change from base Build 12f66d65874936375a8d85969ff80a1e1b8623a1:	0.0%
Covered Lines:	236
Relevant Lines:	236

💛 - Coveralls

nettybun · 2020-07-14T21:03:08Z

If these look good I'll compile a single index.d.ts of all types and upload it to npm as @types/stylis unless you want it in this repo

Andarist

This is good work overall, but personally I would just convert the whole thing to TS if we care about providing good typings by default. Using JSDoc to do this is quirky and far lesser-known skill nowadays, so this doesn't necessarily improve the situation for potential contributors.

@thysultan do you prefer TS or JSDoc?

Andarist · 2020-07-15T08:20:36Z

src/Tokenizer.js

@@ -101,15 +103,16 @@ export function token (type) {

 /**
 * @param {string} value
- * @return {any[]}
+ * @return {[]}


won't this be an equivalent to never[] or something? from what I remember this allocates Element[], I think this wouldn't compile correctly when declared like this when using TS, not sure what about JSDoc though

Hmm. It returns exactly []. Not sure what it's going to be used for afterwards but it's [] at this point

From types perspective, it is important how it is going to be used later - the declared type must match how it is going to be used, just take a look at this demo:
https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABAQwDarhAFASgFyIDaAuogN4BQi1iATgKZQi1IkUC+FFUAngA71EAJRCpBAXnK8BeAOS1R9WQBpEANzQh6BAM5RaMMAHNOAE3oRUyBoggI9dAiLFc0GbDgB0fEDoAWWLQ4QA

Ok fair. I'll use unknown[]. Good call

In a similar fashion unknown[] is not a good fit here because it would require either casting or type refining down the road - we want the result of alloc to be consumable by other code. That's why generic (T[]) would be preferred here.

Look what happens with unknown:
https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABAQwDarhAFASgFyLgDWYcA7mANoC6iA3gFCLOIBOAplCK0jQwL4MGUAJ4AHdogBKIVJIC89URLwByVrPaqANIgBuaEOwIBnKKxhgA5oIAm7CKmQdEEBGbYEZcoQdYp0THZbREU0DGwcBnCg2wA6MRATAAssViiGNzAPVgAmL01QgIjgygAGaiEgA

Andarist · 2020-07-15T08:21:42Z

src/Tokenizer.js

- * @return {any}
+ * @typedef {any} T
+ * @param {T} value
+ * @return {T}


this could use @template T

src/Parser.js

src/Utility.js

nettybun · 2020-07-15T16:32:00Z

@Andarist Thanks for all the feedback! That's very helpful. I went and pushed your suggested changes about @template (wish I knew that existed sooner), Ruleset[], and not realizing the behaviour change in match().

As for changing the codebase to Typescript, I don't think it's worth the fuss for @thysultan who doesn't seem to already use TS in any way, and didn't seem familiar with it in #208. It would add unnecessary complexity to an otherwise simple and small project that can be adequately typed by JSDoc. Furthermore, the author likes to use very terse code in a handful of places that Typescript just wouldn't allow - you'd have to either rewrite it (like I was trying to do with match() earlier) or use a bunch of type assertions like value = element as unknown as Element. I don't think it's worth the headache.

nettybun · 2020-07-15T16:40:54Z

Converting a project to TS is only ever for the author anyway. Users of a library will always need an index.js+index.d.ts. I think it's more important to get that d.ts out the door so people can actually use this lib with their TS code. I'll upload to @types/stylis as soon as we can confirm the emitted declaration from JSDoc is sufficient

nettybun · 2020-07-18T18:18:07Z

Will be merging this: DefinitelyTyped/DefinitelyTyped@master...heyheyhello:master

nettybun

Playing around with the readme examples in Typescript at https://github.com/heyheyhello/DefinitelyTyped/blob/cd84939cbf43f7112bce12b6a3cd6a09c20a0197/types/stylis/stylis-tests.ts

nettybun · 2020-07-18T18:18:50Z

src/Middleware.js


 * @typedef {(
 * 	 element: Element,
 * 	 index?: number,
- * 	 children?: Element[],
+ * 	 children?: (Element | string)[],


See readme.md where apparently this can be a string

nettybun · 2020-07-18T18:19:33Z

src/Middleware.js

+ * 	 children?: Element[] | string,
+ * 	 root: Element,
+ * 	 type: string,
+ * 	 props: string[] | string,


Similarly, this is apparently a string in some cases. Though all references in the codebase treat it as an array (using methods like .join())

Can we put the typedef's(single line) where they are created in the code i.e for the Element typedef we can call it node as it is returned from the node function and put it next to the node functions return JSDOC. For example in https://github.com/thysultan/stylis.js/blob/eff8dc8a0ca05c3a80054ca57915e8a5dba0ab9e/src/Tokenizer.js#L21 to have the following:

/** * @typedef {{parent?: node, children?: node[] | string, root: node, type: string, props: string[] | string, value: string, length: number, return: string, line?: number, column?: number}} node * @param {string} value * @param {nod} root * @param {node?} parent * @param {string} type * @param {string[]} props * @param {node[]} children * @param {number} length * @return node */

Same thing for middleware in https://github.com/thysultan/stylis.js/blob/eff8dc8a0ca05c3a80054ca57915e8a5dba0ab9e/src/Middleware.js#L41 to have the following:

/** * @typedef {(element: node, index?: number, children?: (node | string)[], callback?: middleware) => string | void} middleware * @param {middleware[]} collection * @return {middleware} */

We want Node (or Element, whatever we are going to have it called) to be reusable across different declarations, not sure how defining a @typedef within the same block as a function signature would work. Even if it would work it kinda blends together for me and I wouldn't call this more readable in the end of a day. Defining different types of nodes (CommentNode, DeclarationNode, etc) is also worth exploring - so I think keeping them separate (but probably in the same file) would improve readability.

Defining different types of nodes (CommentNode, DeclarationNode, etc)

That might be too much to represent in JSDocs given the constraints of jsdocs and my reluctants to spear head a full-on TypeScript re-write. If it works i think an inline @typedef has the benefit of highlighting where to the type is sourced/created from avoiding indirection; in contrast: in its free-floating form it raises the question of whether it's from global source.

nettybun · 2020-07-18T18:29:20Z

PR is now open at DefinitelyTyped/DefinitelyTyped#46171

@Andarist would you like to be reviewer and/or co-owner as per bot comment

bell @heyheyhello — you're the only owner, but it would still be good if you find someone to review this PR in the next few days, otherwise a maintainer will look at it. (And if you do find someone, maybe even recruit them to be a second owner to make future changes easier...)

Andarist

I would like to wait a couple of days for @thysultan opinion about this before moving this work to DefinitelyTyped. From my POV it would be better to have those types defined here (even if using JSDoc) to avoid desynchronization of the codebase and types.

I believe we should try to typecheck the codebase to assess that what has been typed is in fact correct - and to do that I think we should add jsconfig.json to the project (or tsconfig.json). At least it's the only thing that made VScode to start typechecking this for me. I've checked out your branch and fixed a bunch of minor issues - there are some other type problems though and I will have to look into them a little bit later.

Andarist · 2020-07-18T22:21:40Z

src/Tokenizer.js

@@ -101,15 +103,16 @@ export function token (type) {

 /**
 * @param {string} value
- * @return {any[]}
+ * @return {[]}


From types perspective, it is important how it is going to be used later - the declared type must match how it is going to be used, just take a look at this demo:
https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABAQwDarhAFASgFyIDaAuogN4BQi1iATgKZQi1IkUC+FFUAngA71EAJRCpBAXnK8BeAOS1R9WQBpEANzQh6BAM5RaMMAHNOAE3oRUyBoggI9dAiLFc0GbDgB0fEDoAWWLQ4QA

src/Utility.js

Andarist · 2020-07-19T08:27:44Z

src/Utility.js

 */
 export function append (value, array) {
 	return array.push(value), value
 }

 /**
 * @param {string[]} array
- * @param {function} callback
+ * @param {ArrayMapCallback} callback


While this is, of course, OK - I don't particularly feel that having this referenced like that is a significant gain. Especially given that in this particular case this type isn't 100% correct - a true ArrayMapCallback should be generic. It's also the only place this type is being used now so I would prefer just writing this thing here inline

It's mostly to differentiate from Middleware which looks super similar and middleware is sometimes passed around as the variable callback 🙄

I agree that the type is not as generic as it could be, but it's actually only used twice in the whole codebase and my preference would be to not have combine at all - use [].map().join(). The author likes to have a lot of aliases though, and I don't think it's worth trying to convince them to change that

Andarist · 2020-07-19T08:32:27Z

src/Tokenizer.js

- * @return {any}
+ * @typedef {any} T
+ * @param {T} value
+ * @return {T}


after a thought - while this works OK with @template it doesn't quite showcase how this function should be used and it is specific to this library and its context. It should always be used together with alloc and I feel that both alloc and dealloc should share the same return type. In this case I would keep using the @template but the accepted and returned types should be T[] instead of plain T, because we always allocate and deallocate arrays.

thysultan/stylis#231 (comment)

thysultan · 2020-07-19T16:26:47Z

add jsconfig.json to the project (or tsconfig.json).

I thought this was only the case for the consumer?

nettybun · 2020-07-19T16:45:09Z

I would like to wait a couple of days for @thysultan opinion about this before moving this work to DefinitelyTyped. From my POV it would be better to have those types defined here (even if using JSDoc) to avoid desynchronization of the codebase and types.

I agree that it's normally ideal for types to exist in the source codebase, but I think its unrealistic in this case. #208 has been open for months. There's not much show of interest from @thysultan about moving forward and I don't blame them - having d.ts in the codebase would be a huge overhaul. The types I have in DT aren't reproducible from tsc as done in 208 - there's actually a small handful of manual edits needed.

I believe we should try to typecheck the codebase to assess that what has been typed is in fact correct - and to do that I think we should add jsconfig.json to the project (or tsconfig.json). At least it's the only thing that made VScode to start typechecking this for me.

This will do type checking. But you'll notice that the codebase is not written with type safety in mind - even the nature of having helper functions like combine and strlen make types awkward. There are a lot of errors.

I've checked out your branch and fixed a bunch of minor issues - there are some other type problems though and I will have to look into them a little bit later.

I just don't think the author wants type problems to be fixed or the project to move more towards TypeScript (or be ported to TS). @thysultan can you comment on your interest or how important it is to you to re-write in that direction?

#208 is months old and I know there are people who wanted types available for this as soon as 4.0 was out.

I'll push to DefinitelyTyped, and if this ever gets merged or type support becomes first class in this codebase I'll be happy to remove the types from DT as documented in https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/README.md#removing-a-package

thysultan · 2020-07-19T17:31:13Z

@thysultan can you comment on your interest or how important it is to you to re-write in that direction?

JSDocs yes, not so much a TypeScript re-write. See my comments on my suggestions on this PR.

Andarist · 2020-07-19T19:58:10Z

add jsconfig.json to the project (or tsconfig.json).

I thought this was only the case for the consumer?

The ultimate goal of this work is to both document the codebase better and to generate .d.ts files automatically. We have to call TS compiler for both and I would rather say that it's better to have it called with explicit settings rather than some defaults (if it even could be called without explicit config). I have only managed to get VScode to typecheck the codebase based on those JSDocs after adding this jsconfig.json file:

This will do type checking. But you'll notice that the codebase is not written with type safety in mind - even the nature of having helper functions like combine and strlen make types awkward. There are a lot of errors.

Yeah, I realize the codebase is using some unsafe, from the perspective of the types, patterns but sprinkling few @ts-ignore here and there should get us pretty far. Or at least that's my hope.

I'll push to DefinitelyTyped, and if this ever gets merged or type support becomes first class in this codebase I'll be happy to remove the types from DT as documented in https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/README.md#removing-a-package

I think it would be better to close that DefinitelyTyped PR for like a week or two. Let us figure this out here in that timeframe and if we won't be able to get the job done you will be able to reopen that PR there.

nettybun · 2020-07-20T17:59:54Z

😍

Nice! It's a lot of code but looks good to me. I imagine it's a bit overwhelming to anyone not familiar with types but certainly a better way to go.

thysultan · 2020-07-20T18:52:37Z

src/Middleware.js

 * @return {Middleware}
 */
 export function rulesheet (callback) {
 	return function (element) {
 		if (!element.root)
+			// @ts-ignore


Not a fan of the ts-ignore comments, considering this commit essentially create a full type-definition we could just shop a typings.d.ts definition file with this in it instead of JSDoc comments?

Not a fan of the ts-ignore comments

Plan to remove them, they were only somewhat helpful to me when I've been typing this.

considering this commit essentially create a full type-definition we could just shop a typings.d.ts definition file with this in it instead of JSDoc comments?

Yeah, we can totally do that - my idea was just that the types were sort-of already here, so I've tweaked those instead of providing a separate set of types. Would you like me to bring back old&simple JSDocs and gather all of those types within .d.ts file?

thysultan · 2020-07-20T18:53:51Z

src/Serializer.js

@@ -1,11 +1,11 @@
 import {IMPORT, COMMENT, RULESET, DECLARATION} from './Enum.js'
 import {strlen, sizeof} from './Utility.js'

-/** @typedef {import('./Middleware.js').Element} Element */


Are typedef's not global? i.e is there a need to import them?

Andarist

I've pushed out some changes. They are by no means final - just a base for further discussion, but actually it shouldn't take that much to finish this work as this is already functioning quite well. We only need to decide how granular etc our types should be.

Apart from a couple of places where I've added @ts-ignore comments because variables were reused for new data of a different type the codebase was pretty straightforward to type. While having type-checking on in the codebase brings value and could potentially catch some issues early here, those suppressing comments litter the code a little bit and it's hard to put them at a faulty expression level so they work now on the whole statements which tend to be long. So I would say that in this case removing them and turning off the type-checking for internals would be preferred.

Andarist · 2020-07-20T19:41:15Z

src/Enum.js

@@ -1,20 +1,74 @@
+/**


"had" to add those @type declarations because those use var and not const so their type is widened to a string but actually we want some of them to act as sentinel values in unions, so it is required for them to have a "discrete" value

Andarist · 2020-07-20T19:57:52Z

src/Middleware.js

- * 	 array: string[],
- * 	) => string
- * } ArrayMapCallback
+ * @typedef {NodeBase & {


sharing this common part like that makes IDE hints somewhat unreadable as it tries to expand those types instead of using their names, I think it's some quirk with JSDoc support as this doesn't happen as easily when working with regular TS code

for this reason, it might make sense to just inline this "base" everywhere, those typedefs would get lengthy, but we can put the common part last to counteract this a little bit, worth a discussion

Andarist · 2020-07-20T20:08:55Z

src/Middleware.js

+ }} RulesetNode
+
+ * @typedef {NodeBase & {
+	type: '@keyframes'


Creating separate types for all possible nodes is not technically correct because the runtime doesn't actually care for the most part - so it is possible to feed such a string to compile that one of produced Nodes would not match against any of those that are defined here.

Specifying them here makes working with the compiled output easier though because it is natural to differentiate node types based on their .type property and this works perfectly with TS - after such a check it is able to limit the type of a node within a conditional block to the one matched by a condition, like in here TS can know that for a RuleNode props has to be an array of strings

Andarist · 2020-07-20T20:13:49Z

src/Middleware.js

+* @typedef {NodeBase & {
+	type: '@counter-style'
+	props: string[]
+	children: DeclarationNode[]


This is, somewhat, an interesting case as well - I've limited the children here to DeclarationNode[] as it's the only thing that makes sense but it's also not guaranteed by the runtime. But again - by grouping different types and providing logical children/parent/root for all of them we would provide a better DX. The "correct" AST allows only for certain relations between different node types and knowing them is very valuable for developers - when working with Babel plugins I use @babel/types docs a lot.

Andarist · 2020-07-20T20:15:56Z

src/Utility.js

 /**
- * @param {number}


old definitions were not picked up by the IDE at all - I think those can only be used for actual function declarations and not for defining types when assigning to a variable like this

Andarist · 2020-07-20T20:16:46Z

src/Tokenizer.js

 	return {value: value, root: root, parent: parent, type: type, props: props, children: children, line: line, column: column, length: length, return: ''}
 }

 /**
 * @param {string} value
- * @param {Element} root
+ * @param {Node} source


i've renamed this param as root was IMHO a confusing name for this - given that we have a .root property on Nodes

Andarist · 2020-07-20T20:20:06Z

src/Parser.js

- * @param {Element} root
- * @param {Element?} parent
+ * @param {Node?} root
+ * @param {Node?} parent
 * @param {number} index
 * @param {number} offset
 * @param {string[]} rules
 * @param {number[]} points
 * @param {string} type


potentially we could explore limiting this to a particular union of strings and define the whole function in a similar fashion as node

* Types for Stylis 4.0 * Add default export for Stylis Co-authored-by: Piotr Błażejewicz (Peter Blazejewicz) <peterblazejewicz@users.noreply.github.com> * Improved T generics thysultan/stylis#231 (comment) Co-authored-by: Piotr Błażejewicz (Peter Blazejewicz) <peterblazejewicz@users.noreply.github.com>

nettybun · 2020-07-25T19:12:43Z

@Andarist I think your changes would be great as a PR to update the typings on DefinitelyTyped. The typings that are available+published now as @types/stylis work well for developers using stylis, but your changes would benefit people trying to write middleware and hack on stylis itself. Specifically adding node subtypes and renaming parameters (i.e root to source) would benefit developers who are working with stylis internals - which may be groups like emotion and styled-components (who are currently stuck on V3).

If you're interested in opening a PR there I'll approve them and the tests can be edited to cover more type-specific usecases like writing middleware.

Andarist · 2020-08-02T15:21:00Z

Sorry for being MIA lately - had a lot on my shoulders and couldn't find time to get back to this PR.

@heyheyhello I think we have every intention of shipping those types (after some redacting) as part of the Stylis itself. We just need to figure out how we want to do this - which shouldn't take us that long. I hoped you wouldn't rush with this DefinitelyTyped PR too much as now we'll be in this weird situation where types will be published (soon-ish) both within stylis and @types/stylis packages which will only confuse some users.

nettybun · 2020-08-02T16:04:10Z

@Andarist There's no issue with that. It's something that DefinitelyTyped plans for and has deprecation warnings for. It's easy to open a PR in DT to have the types taken down :) If you shipped types tomorrow no one installing @types/stylis would see an issue; the typings would still resolve.

I didn't feel rushed with DT, but I've seen many PRs stay open for months or years so why not have the ball rolling now? I didn't see any reason to stop progress

Andarist · 2020-08-02T16:08:08Z

What will happen with people who have already installed @types/stylis and who will upgrade to a new Stylis with types included in it? It's a genuine question - I'm not sure which one wins in such a situation or if they cause a conflict or not.

nettybun · 2020-08-02T16:59:59Z

I'm pretty sure it's always setup to prefer local types. I just checked too:

I copy/pasted the node_modules/@types/stylis into node_modules/stylis/ and added the "types": "index.d.ts" to package.json, and then I comment out the serialize method just to be sure it updates. Works as expected, and hovering on the "stylis" import shows the correct local path despite having @types/stylis installed

nettybun · 2020-08-02T17:04:31Z

I didn't feel rushed with DT, but I've seen many PRs stay open for months or years so why not have the ball rolling now?

Also a huge push for me is that my memory's not great - it's been 20 days since this PR was opened and honestly I don't remember writing the types. There's a small window before I move onto other things...

nettybun · 2020-08-04T04:23:36Z

@thysultan

Thought I'd mention now that I've been using @types/stylis for a bit... The huge amount of commonly named exports that stylis has is problematic: things like next, length, and substr. My editor autocomplete/autoimport messes up when I type nex<Enter> hoping to resolve "nextParent" (my variable name) but it auto-imports next from stylis 😒

Not sure the best way forward. If not remove exports then how about renaming or prefixing?

Andarist · 2020-08-04T06:51:14Z

@heyheyhello we can't just rename them in v4 as that would be a breaking change, so even if we would have provided aliases for those the problem for you would still persist. It really feels like your IDE's algorithm could be improved to prefer local variables? Can't it be configured somehow? I also don't see this much of a problem - one library's API choices can't be dictated by IDEs behaviors.

thysultan · 2020-08-05T12:51:33Z

@heyheyhello Why would it try to autocomplete for exports you haven't imported? unless you're importing everything?

import * as stylis from 'stylis'

stylis.next(...)

nettybun · 2020-08-05T16:08:10Z

@heyheyhello Why would it try to autocomplete for exports you haven't imported? unless you're importing everything?
import * as stylis from 'stylis'

stylis.next(...)

That's a great idea thanks. Star import is the way to go. Also my editor does auto imports. I think vscode offers it by default? So importing only one thing from stylis tells the editor to be ready to offer all symbols and just patch the import statement as needed.

Sorry I thought it was a common feature. Good fix!

nettybun · 2020-08-16T20:26:56Z

Hey I'm tired of seeing this on my homepage so I'll close this. I've already done all the changes to @types/stylis and don't want this to hang forever like #208. Life's too short. Thanks for all the help with it @Andarist! Looking forward to any future PRs that propose better types.

maxmilton · 2020-08-20T03:09:17Z

@heyheyhello great work on @types/stylis, thanks for your efforts! I had been using my own until I noticed it in your last comment.

Shame about the poorly typed JSDoc annotations... but now with @types/stylis it's not an issue for the lib consumers :)

* Types for Stylis 4.0 * Add default export for Stylis Co-authored-by: Piotr Błażejewicz (Peter Blazejewicz) <peterblazejewicz@users.noreply.github.com> * Improved T generics thysultan/stylis#231 (comment) Co-authored-by: Piotr Błażejewicz (Peter Blazejewicz) <peterblazejewicz@users.noreply.github.com>

nettybun added 2 commits July 14, 2020 11:49

Better JSDoc types

8e02fab

Other type fixes and cleanup

33e12ad

nettybun commented Jul 14, 2020

View reviewed changes

src/Parser.js Outdated Show resolved Hide resolved

nettybun commented Jul 14, 2020

View reviewed changes

src/Tokenizer.js Outdated Show resolved Hide resolved

nettybun commented Jul 14, 2020

View reviewed changes

src/Utility.js Outdated Show resolved Hide resolved

nettybun commented Jul 14, 2020

View reviewed changes

src/Parser.js Outdated Show resolved Hide resolved

Build fix

8e24575

Support ES5

f8082a7

nettybun requested a review from thysultan July 14, 2020 22:47

Andarist reviewed Jul 15, 2020

View reviewed changes

nettybun added 3 commits July 15, 2020 09:25

Hard to understand terse code... reverting

a955be6

Learned about @template in JSDoc

3651a7c

Rulesets to Ruleset[]

17eb12f

Types based off the readme documentation

eff8dc8

nettybun commented Jul 18, 2020

View reviewed changes

nettybun mentioned this pull request Jul 18, 2020

Add types for Stylis 4.0 DefinitelyTyped/DefinitelyTyped#46171

Merged

12 tasks

Andarist reviewed Jul 19, 2020

View reviewed changes

Fix T generics from @Andarist

cb08539

nettybun added a commit to nettybun/DefinitelyTyped that referenced this pull request Jul 19, 2020

Improved T generics

881b34f

thysultan/stylis#231 (comment)

Ensure that declared JSDoc types are correct

ceb1b04

thysultan reviewed Jul 20, 2020

View reviewed changes

Andarist reviewed Jul 20, 2020

View reviewed changes

nettybun closed this Aug 16, 2020

Better JSDoc types #231

Better JSDoc types #231

Conversation

nettybun commented Jul 14, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

coveralls commented Jul 14, 2020 • edited Loading

Pull Request Test Coverage Report for Build 27c44ce386aa07c6c2785babfb86216bf855799f-PR-231

💛 - Coveralls

nettybun commented Jul 14, 2020

Andarist left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nettybun commented Jul 15, 2020 • edited Loading

nettybun commented Jul 15, 2020

nettybun commented Jul 18, 2020

nettybun left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thysultan Jul 19, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nettybun commented Jul 18, 2020

Andarist left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thysultan commented Jul 19, 2020

nettybun commented Jul 19, 2020

thysultan commented Jul 19, 2020

Andarist commented Jul 19, 2020

nettybun commented Jul 20, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Andarist left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nettybun commented Jul 25, 2020

Andarist commented Aug 2, 2020

nettybun commented Aug 2, 2020

Andarist commented Aug 2, 2020

nettybun commented Aug 2, 2020 • edited Loading

nettybun commented Aug 2, 2020

nettybun commented Aug 4, 2020 • edited Loading

Andarist commented Aug 4, 2020

thysultan commented Aug 5, 2020

nettybun commented Aug 5, 2020

nettybun commented Aug 16, 2020

maxmilton commented Aug 20, 2020

coveralls commented Jul 14, 2020 •

edited

Loading

nettybun commented Jul 15, 2020 •

edited

Loading

thysultan Jul 19, 2020 •

edited

Loading

nettybun commented Aug 2, 2020 •

edited

Loading

nettybun commented Aug 4, 2020 •

edited

Loading