-
Notifications
You must be signed in to change notification settings - Fork 142
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
Improve typings #45
Improve typings #45
Conversation
1 similar comment
2 similar comments
1 similar comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR! Made some minor comments about style and being consistent with the rest of the repo (please look over typings-test.ts
again), but I'll look more deeply later.
@@ -14,7 +14,7 @@ | |||
"lint": "eslint src/ test/", | |||
"prepublish": "npm test && npm run build", | |||
"pretest": "npm run lint", | |||
"test": "cross-env NODE_ENV=test nyc mocha" | |||
"test": "cross-env NODE_ENV=test nyc mocha && tsc" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use the posttest
lifecycle hook for tsc
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, never use posttest before. :)
@@ -0,0 +1,68 @@ | |||
import { FluxStandardAction, isError, isFSA } from '../src' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer to see semi-colons to be consistent with index.d.ts
and the JS files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok.
1 similar comment
Updated based on feedback. 🌷 |
1 similar comment
The last change I made worth debating. On one side it helps on the type guard usage, on the other side it makes action creation harder: What do you think? |
I think it is the right change. When Would that be any case that this is not true? |
cc/ @tkqubo who add typings to DT. |
Since `payload` and `meta` is generic, user can specify `void` or `undefined` to indicate it does not present. Removing the optional designation improves type guard. see `isCustomAction4()` for example
@JaKXz do you have anything for me to change before we can merge this? 🌷 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@unional so sorry for the delay! I finally have some OSS cycles again. 🌹
I have a couple more notes:
- please run
yarn
to updateyarn.lock
- the
posttest
action that runstsc
will return an exit code of 1 if there is a problem with the typings, correct?
There are some more nitpicks I could make in typings-test.ts
about code style [e.g. missing semicolons 😱 ] - can that file [and other .ts
files in the repo] be linted somehow?
And last question, what is the status on the typescript issue you posted earlier? I saw that it's still open and was updated recently, but it's a long thread so I haven't read it closely yet. Will that be a fix that comes in later or does it block this PR?
@JaKXz good to hear from you!
It still have? Seems like I'm getting very comfortable with my own linting standard 😛 .
Yes, but since it is
I personally do not recommend checking in
They are working on it, likely will still take a few months to land. We can update the typing when that is released and get mainstreamed. |
Found the comment I made about |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@unional re: yarn.lock
- as a maintainer it has actually made my life much easier and helped me catch a number of issues regarding deps before merging PRs. I think the purpose of the yarn.lock
file is to give some reassurance about what versions of dependencies and sub-dependencies are resolved & installed. Having a way of knowing which dependencies are installed, and then being able to investigate why certain dependencies are installed at certain versions are reassurances we haven't had before with node modules.
It makes breakage detection harder for the maintainer.
I disagree with this statement. I am able to trace the history of my dependencies (and their dependencies) in a git bisect
. I am going to ask that you update the yarn.lock
before I can merge this PR.
re: linting - I'm just considering the cost of maintenance [so if people want to contribute it the future, how can we make it so that they can get feedback about code style from a robot rather than me having to comment on every line of their changes]. Do you know of a houndCI for TypeScript? Or would we have to add those dependencies to the project [which I don't really prefer since this is just a generic JS project]?
Also, it would be ideal if the tsc
command exited with a non-zero code when the compilation fails so that there's feedback that the typings have broken. I'm pretty sure if posttest
fails, any commands that depend on test
will not execute.
perhaps https://github.com/nzakas/eslint-plugin-typescript would help? |
2 similar comments
It does exist with non-zero. I was just concerning that
yes, that's true for applications. For modules/packages, IMO it will hide the problem until a user reports it. E.g. if your module depends on This is because during consumption, the The article (https://yarnpkg.com/blog/2016/11/24/lockfiles-for-all) about devDeps vs deps is correct thou. All in all, maybe this topic is still in flux and it will clear out as more module authors adopt one way or the other. This is just a friendly discussion. 🌷 Maybe using I have updated the |
"lodash.isplainobject": "^4.0.6", | ||
"lodash.isstring": "^4.0.1", | ||
"lodash.issymbol": "^4.0.1" | ||
"lodash.issymbol": "^4.0.1", | ||
"typescript-eslint-parser": "^1.0.2" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think all typescript dependencies should be in devDeps
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, of course. 😛
@unional thank you for your thoughts, hard work, and patience on this. I'm excited to get it merged after one last issue and release v1.1.0 :) |
2 similar comments
}, | ||
"dependencies": { | ||
"eslint-plugin-typescript": "^0.1.0", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
missed this one as well
I have added a few things:
isFSA
andisError
This allows users to specify the type of the
payload
andmeta
easily.See
typings-test.ts
for examples.In the future, I would like to make the
Meta
type optional.But need to wait for microsoft/TypeScript#2175
For now, I think this is the best it can get. 🌷