-
-
Notifications
You must be signed in to change notification settings - Fork 133
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
Implement TypeScript types #282
Comments
Eventually there will be types in this package, but they will also be Deno compatible, and most likely JSDoc types that will be defined in the actual published code and will also be used when generating the readme API docs. I've been doing intense research and development over the past 6 months in particular about a universal pattern for type safe Node.js/Deno/browser/JSPM code, that is buildless and works for pure ESM modules ( I've figured out how to get universal Node.js/Deno/JSPM packages working for everything except types, and am currently republishing everything accordingly. I'll do another wave of updates once types are possible. |
.d.ts
with this package
@jaydenseric Could we release another version with the TS types? Or anything you would like to wait with along the next bump? |
@glennreyes I really wanted to update the Perhaps if you were to figure out a PR there it would expedite things? It would be a good way to help. I'm currently updating the Apollo upload examples project so I can test the I was considering also switching |
Any idea how to resolve this TS error when using 15.0.0, thx
|
@Bidek56 have you tried these tips: #282 (comment) Are you importing |
|
So it turns out that tsconfig.json Changing it to: |
@Bidek56 I don't think that fixes the problem of the types not resolving correctly; it just hides that they are missing. |
Hmmm, maybe it's a ts-node problem b/c it works with |
It's a ts-node config problem. When using ts-node, the tsconfig.json needs to be:
|
Is there any other solution for this problem if i don't want to use unstable NodeNext with typescript@next? |
@dzyubanov it's not unstable, it's stable in TypeScript v4.7: |
I mentioned this on another issue but I did need to set |
I am using TS 4.7.2 but it was an issue with ts-node solved by adding to tsconfig.json as shown above. |
Regarding https://code.visualstudio.com/docs/languages/jsconfig#_what-is-jsconfigjson I use |
@jaydenseric Any strong reasons why we don't want this library to ship types that just work with a If yes, I think this would need definitely some docs. |
I took source of this library, changed
and after that step Can I hope something like this could happen during publishing of this library? Reason it's pretty important for me, is in my project, setting |
@glennreyes yes, there are several very strong reasons. One that is easy to explain, is that when a Deno user imports a module from a simple CDN that just dumbly serves the package files that were published, the types will be perfectly available without having to do anything other than importing the module. For example: import Cache from "https://unpkg.com/[email protected]/Cache.mjs"; Some other benefits (not the only ones):
It would take a much longer comment to explain the downsides to alternative approaches like triple slash reference comments in the published modules, or
Regarding docs, thanks for the suggestion but I disagree that the burden is on every individual package to teach users how to use tools like TypeScript. I would be copy-paste synchronising teaching material across something like 20+ readmes. And all of that content would be irrelevant to Deno users anyway, as they don't need to do any kind of special config to enjoy types from JSDoc comments in JavaScript modules. Node.js TypeScript users need to be aware that there are a few different ways that packages provide types, and not set TypeScript config that excludes some. I'm getting more complaints in the few days I added types here than in the years I provided none at all, and I'm not doing anything invalid. They are good types! |
@mlesin graphql-upload/GraphQLUpload.js Line 1 in b1cdd2a
|
@jaydenseric I tried hard and still can't find variant of {
"compilerOptions": {
"module": "NodeNext",
"maxNodeModuleJsDepth": 10,
"declaration": true,
"removeComments": true,
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"allowSyntheticDefaultImports": true,
"lib": ["ESNext", "DOM"],
"target": "ESNext",
"sourceMap": true,
"outDir": "./dist",
"baseUrl": "./",
"incremental": true,
"skipLibCheck": true,
"strict": true,
"strictNullChecks": true,
"noImplicitAny": false,
"strictBindCallApply": false,
"forceConsistentCasingInFileNames": false,
"noFallthroughCasesInSwitch": false,
"noUncheckedIndexedAccess": true
}
} I am importing library this way: import GraphQLUpload from 'graphql-upload/GraphQLUpload.js';
import type { FileUpload } from 'graphql-upload/processRequest.js'; vscode writes this under first quote right after "import GraphQLUpload from":
And as a result, GraphQLUpload is of type any. |
@mlesin if you are using TypeScript is really not helpful with their error messages in some of these situations; hopefully in time they will fix them because |
The "cleanest" solution found (still you lose type safety) is to import the // eslint-disable-next-line @typescript-eslint/ban-ts-comment
// @ts-expect-error See Github issue why this exists - https://github.com/jaydenseric/graphql-upload/issues/305#issuecomment-1135285811
import GraphQLUpload from "graphql-upload/GraphQLUpload.js"; The same goes for the middleware as well. Type safety can still be opted-in if you really need it by |
Ok, I guess I'm screwed if I don't want to allow JS in my project, eh? Let us all sacrifice for the Deno people |
@Faithfinder firstly, why is it a big sacrifice to enable Secondly, scorning Deno and browser people is not productive and is going to age like milk. |
Sorry about being.... Unfriendly. I was just upset having to dive through these topics, first about no Still.
Secondly, I actually don't want types inferred for random libraries in node modules. Sure, you might be shipping JSDoc types, however most libraries if not shipping As for Deno... It might be the future or whatever, however we live in the present. Some future (not even current) support for Deno does not make me feel like I spent my time productively reading multiple issues where you define your stance. Fact is, in the current ecosystem, after you download the package you either get the types working automatically, or you download the |
Have 6 projects in production using this feature Perfoming this change without publicly notify it nor enable well defined migration path is must in these cases. This "publishing-behavior" causes instability and breaks the trust we give to the library. For these we are dropping the usage of this package. |
Note that |
It would be better if TypeScript types were exported from this package. As a user it simplifies using this library and as an author that should make it easier to supporting latest versions. Let me know and I can help getting TypeScript types from Definitely typed to this package.
The text was updated successfully, but these errors were encountered: