I've been using CaslJS (#casl/ability) for a few years now and am now trying to migrate my typescript project from CommonJS to ESM.
I've got my whole project migrated, but CaslJS throws errors about missing declaration files, e.g.:
node_modules/#casl/ability/dist/types/types.d.ts(1,32): error TS7016: Could not find a declaration file for module '#ucast/mongo2js'.
I've done a bit of digging into this, and isolated the problem to the "moduleResolution": "node16" configuration in tsconfig.json.
With this set to node the project builds fine (but the build produces commonjs, not esm)
Any help with fixing these type errors would be appreciated as Casl is now the only blocker to moving to ESM.
I've been able to replicate this in a new example project here: https://github.com/egmacke/rush-examples/tree/master/casljs-esm-node16
This issue has now been resolved. The issue was actually with the #ucast/mongo2js library not exporting it's types correctly.
For reference, https://github.com/stalniy/casl/issues/734
Related
In TypeScript, say I want to have the user use my module's "internal" types so they can properly type their own variables when using my module - do I just export literally everything from my index.ts file to accomplish this?
// index.ts
export * from './file1' // uses types/interfaces defined in file1types
export * from './file2' // uses types/interfaces defined in file2types
export * from './types/file1types'
export * from './types/file2types'
Do .d.ts files help me accomplish this, or are they only for non-TS projects? Does tsconfig.json's option declaration: true help me accomplish this by generating a .d.ts for every TS file? Is this an alternative to exporting everything from a single index.ts file?
And if declaration: true does help me accomplish this, how would the user use all those generated .d.ts files within the build folder?
I would greatly appreciate some clarification as to how one typically exports types in TS projects. Thanks in advance.
For those who are like me, and have made sure declaration: true is set in your tsconfig.json, and that your build process correctly creates the corresponding .d.ts files to the appropriate directory pointed to by your package.json file, AND STILL somehow can't access the internal types of your module when testing on an external project -- try restarting the TS server in VSCode (assuming you're using VSCode)
So much time was wasted trying to figure this out, only to realize Typescript was functioning fine and I was being sabotaged by my IDE.
Without declaration files you can develop a package in TypeScript, compile it and expose it to other users as JavaScript code. Including them also allows TypeScript developers to use the package with any types you defined in it. They can get more type information whilst working with your library, such as required arguments types, function return types etc, as well as warnings from their IDE/Intellisense when there are conflicts.
The declaration: true in the file tsconfig.json instructs the TypeScript compiler to output declaration files (.d.ts). Often they are bundled in a single file e.g. index.d.ts and then a "types": path/to/index.d.ts field is added to the library's package.json file to inform TypeScript where to look for the types (when a user imports the package).
I have the following TypeScript code:
const myMap = new Map([["name", 5]]);
for (const foo of myMap.values()) {
console.log(foo);
}
When I run this code in node (v8.12.0) directly, it works and prints out "5" to console.
If I run this exact same code in a Jest test, it never executes the contents of the for loop. It runs the for condition and then just skips past the loop, never actually enumerating the values.
Why is that? Is there something about the JS runtime used by Jest (isn't it node?) that doesn't support for..of over iterables?
Thanks!
After a very long investigation, I have gotten to the bottom of this. Important background information about the solution:
When targeting older ECMAscript versions like ES3 and ES5 with the TypeScript compiler, using for..of loops to iterate over Iterable collections is not supported by default. If you want to use for..of with Iterable, you have to either target something newer than ES5 or use the --downlevelIteration flag.
To use Jest with a TypeScript project, you use ts-jest. At least, I was. I think you can also use babel somehow but I think ts-jest is preferred.
When using ts-jest, by default it tries to use the tsconfig.json file that the project uses -- which, as far as I can tell, means the one that is next to the jest.config.js file you are using (or the current directory if you aren't specifying a jest.config.js file). If it cannot find a tsconfig.json file in the project directory, it uses the default TypeScript compiler options. The default compiler options cause the TypeScript compiler to target ES3 or ES5 (the ts-jest docs claim it defaults to ES3 but that ts-jest overrides the default in this case to be ES5). --downlevelIteration is not on by default.
With all this in mind, I was able to figure out that ts-jest was not able to find my project's tsconfig.json file and so it was running my tests using the default settings, which meant targeting ES5 and not allowing downlevelIteration, so all my for..of loops over Iterable didn't work. The reason it couldn't find my tsconfig.json file is because my jest.config.js file was in a different directory (higher up in the tree) and even though I was running jest from a directory with a tsconfig.json file, ts-jest was not looking in the "current" directory but was instead looking in the directory that I pointed jest at for my jest.config.js file, which did not contain a tsconfig.json.
My solution to this was to rework my directory structure a bit and leverage the tsConfig option of ts-jest to tell it where to find my tsconfig.json file, which made everything "magically" work since my tsconfig.json file targets es2018, which supports for..of iteration over Iterable.
One alternative solution I considered but quickly disregarded was feature of the aforementioned tsConfig setting to directly set the --downlevelIteration compiler option in the jest config. I chose not to do that because, while it would have fixed this specific problem, it would not have fixed the larger problem which is that my Jest tests were compiling my TypeScript with different flags than my production code! It just so happens that only current problem caused by this was my for..of loop misery.
A quick postscript: the way I eventually made headway on this issue is by stumbling across the diagnostics option in ts-jest. Once I set it to true, when I tried to run my tests, an error like this was displayed:
TypeScript diagnostics (customize using [jest-config].globals.ts-jest.diagnostics option): src/foo.ts:163:47 - error TS2569: Type 'Map<Guid, FooInfo>' is not an array type or a string type. Use compiler option '--downlevelIteration' to allow iterating of iterators.
It seems like TS compiler errors should be displayed (and cause test failures) regardless of whether or not ts-jest "diagnostics" are enabled but shrug.
To use an exported type in .ts file one has to add import it
import {jQuery} from 'jQuery'
Now when I use this I do not get intellisense, I still need to do npm install #types\jQuery to get that.
So without #types, above statement just infers that during typescript bundling include this file.
Now if I install #types then without adding any other code, I do start getting intellisense.
So is it like above statement is dual purpose.
During bundling using typescript/webpack, it tells to bundle these files as dependency and during compilation, it tells to include .d.ts rather than actual code file?
Why this question: I am trying to move angular1 to typescript and I can use angular.whatever in .ts file even without importing it? Not getting why this is happening. It should give me error asking me to import angular
Not sure I get your question 100% but I can try to explain a bit. The javascript runtime won't have a static check, it is just during the compilation time. If you tell typescript that your variable/function/etc. is of type 'any' then it will just allow you to do anything with it. Eventually the generated code is the same, whether it is checked or not. If you don't have corresponding variable during runtime, you will get an error. Typings are used to just "teach" ts compiler about the actual types of variable for static compilation.
So during compilation no .d.ts is included anywhere, this is just for static type check.
As to why you can access angular, I suppose it is because of d.ts contains the definition and by using #types/angular you let ts compiler know about it.
Check here. The .d.ts files includes global variable angular, that's why you can use it without importing I think.
P.S. Not sure 100%, but seems like it is this line:
declare var angular: angular.IAngularStatic;
You can try deleting this line and see if you get your error :)
I'm trying to use GridFSBucket and related classes in my node typescript project but the typescript definition I have gotten from DefinitelyTyped doesn't seem to support it.
How can I do one (or more) of the following:
Find an updated version? Does someone have one?
Tell typescript to ignore just these particular items?
Use a merge declaration where I can add GridFSBucket and related as
a top level declaration so typescript will stop complaining? I tried
doing this and kept getting an error that I cannot add to top level
declarations.
When I was trying to do a merge declaration before I was doing it inside the file I was having the typescript error in (trying to be lazy). Moving the declare stuff into its own file (my_custom\mongodb.d.ts) I am able to add the stuff I need. To be clear I am still compiling against the official mongodb d.ts as well.
...
export class GridFSBucket {
constructor(db, options:IGridFSBuckerOptions);
openDownloadStream:(id,options?:IOpenDownloadStreamOptions)=>GridFSBucketReadStream;
}
...
Has anybody got a setup working in which module 1 using typescript is referencing another module 2 also with typescript and both use tsd types such as node.d.ts ?
I have no problem compiling both and using them, as long as i simply require module 2. But as soon as i use import instead, i get into duplicate identifier hell, due to the fact that source files in both modules import e.g. node.d.ts typings from obviously different paths. Classes in both projects use e.g 'streams' or 'lodash' thus both use them in typings and thus use the /// reference syntax. The tsconfig in both projects excludes typings.
Typescript has come a long way since this was asked, and it's now much easier. You can link the proper files in package.json:
{
"main": "library-commonjs.js",
"module": "library-es6-module.js",
"typings": "library-commonjs.d.ts"
}
main is used by packages using CommonJS and Node.js module resolution. module is used by packages supporting ES6 imports. And typings is followed by Typescript (currently Typescript 2.2) to resolve type definitions for the package.
After struggling with this, I spent some time creating a typescript boilerplate/starter project that demonstrates how to do it properly:
https://github.com/bitjson/typescript-starter
That project includes a lot more documentation, and several examples of how to import code from typescript projects.
EDIT: With TS 2.2 this has gotten quite a lot better. See the accepted answer.
It seems this is not really possible yet in typescript 1.8.x. But they seem to work on it via https://github.com/Microsoft/TypeScript/issues/7156.
Also the problem is supposedly mitigated by using a jsconfig.json which should be used by VScode (see https://blogs.msdn.microsoft.com/vscode/2015/07/06/visual-studio-code-es6/). Sadly i didnt get it working yet.