You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My code builds correctly (microbundle 0.13 + TypeScript 4.2.3) but the type declarations are not found, so the imports are implicitly typed "any":
Could not find a declaration file for module 'gl-matrix/mat4'.
'$PROJECT/node_modules/gl-matrix/cjs/mat4.js' implicitly has an 'any' type.ts(7016)
In a TypeScript project, this is easiest to spot with "noImplicitAny": true, enabled in tsconfig.json, because it becomes a compiler error. I found this issue in the process of converting a codebase to the TS "strict" mode.
Are these entrypoints a valid way of importing, and do you know if it's possible to provide type declarations for them? If I import from the root as import { mat4 } from 'gl-matrix' then mat4.determinantwill have the correct type information, so certainly the type information exists, but is just not accessible when imported in the other way. Unfortunately I think the latter syntax defeats tree-shaking and will increase my library's bundle size, so I'd prefer to use the deeper entrypoints.
Thanks!
The text was updated successfully, but these errors were encountered:
I've been importing from
gl-matrix
with the following syntax:My code builds correctly (microbundle 0.13 + TypeScript 4.2.3) but the type declarations are not found, so the imports are implicitly typed "any":
In a TypeScript project, this is easiest to spot with
"noImplicitAny": true,
enabled intsconfig.json
, because it becomes a compiler error. I found this issue in the process of converting a codebase to the TS "strict" mode.Are these entrypoints a valid way of importing, and do you know if it's possible to provide type declarations for them? If I import from the root as
import { mat4 } from 'gl-matrix'
thenmat4.determinant
will have the correct type information, so certainly the type information exists, but is just not accessible when imported in the other way. Unfortunately I think the latter syntax defeats tree-shaking and will increase my library's bundle size, so I'd prefer to use the deeper entrypoints.Thanks!
The text was updated successfully, but these errors were encountered: