Open teidesu opened 6 months ago
In Deno, you have to explicitly link your .d.ts
files to your .js
files because Deno's module resolution algorithm does not probe for sibling files. See https://docs.deno.com/runtime/manual/advanced/typescript/types#using-the-triple-slash-reference-directive.
In your case, you want to add a /// <reference types="./mod.d.ts" />
to your JS file.
i believe error message/docs could be improved then. this difference is currently not mentioned anywhere in jsr specifically, so coming from node background this behavior is pretty unexpected.
adding ///
reference does fix it, thanks!
Yes - we'll improve the docs and error message.
@lucacasonato I just ran into this as well. Would you consider adding a types
field to jsr.json
specifically for JS entrypoints to specify their .d.ts
files?
The reason is that this is a bit of a mess to implement for each package, as including the triple-slash directive before tsc
runs causes errors, so my process ends up like this:
tsc
on the rolled up fileI understand that Deno doesn't crawl around the directory looking for .d.ts
files, so maybe allowing us to explicitly specify the type declarations file in jsr.json
could improve the developer experience?
You can now specify // @ts-self-types="./types.d.ts"
instead of the triple slash reference comment. This doesn't break TypeScript so you don't need to do it after type checking :)
Ooh thank you! I will give that a try.
which leads to jsr resorting to trying to infer types trivially, and as a result - failure to use the library altogether.
mcve
deno.json
mod.js
mod.d.ts
expected result
jsr uses d.ts files for typings and doesn't try to infer them on its own
actual result
jsr warns about "slow types" when publishing and advises to add d.ts files (which are already there):
additional context
due to this bug,
export const ns
from the mcve, whose type can't be trivially inferred, results being unusable at all: