If you know how to fix the issue, make a pull request instead.
@types/xxxx package and had problems.Definitions by: in index.d.ts) so they can respond.because this declares the Big.js object in the global scope, when using code modularly in Node/in frontend mobile/browser codebases using webpack, where the library is not present in the global scope, the typings say that it always is; this has caused me to introduce bugs multiple times now thinking that the code is fine, but it's not.
I'm not sure how other libraries like jquery or what not handle this issue, or if they just have the same problems.
Example of bug in our codebase triggered by this: https://github.com/rahafoundation/raha-api/pull/120
Hi, you should be able to control which global types are imported with the types property in the compilerOptions of your tsconfig.json. When it is not specified, all global types from node_modules/@types will be imported. You can specify as an array the names of the packages from which to import global types. So "types": ["big.js"] would only import the global typesof big, and no others and an empty array will keep all the global types out of the scope.
This won't affect explicit imports or custom global typings in your source, only the ones from node_modules.
Let me know if this helps!
oh wow I didn't know that's how the Typescript types property works! That's really counterintuitive from the name of the key in tsconfig.json. Good to know, hope other people find this ticket for posterity for other similar problems.
Posted a StackOverflow question for visibility here: https://stackoverflow.com/questions/52621222/how-do-you-exclude-global-types-declared-in-typescript-definitions/52621223#52621223
Yeah the types / typeRoots is all very confusing and not so well described in the documentation.
I'm glad this helped!
OK, so the advice to use "types": [] doesn't seem to work. I thought it might be some weird thing with my project, so I created a test project to confirm. I have made two observations thus far:
"types": [] does not seem to do anything with types from big.jsTypings for big.js seem to pollute the global name space if I import it from within my own code:
// test.ts file
import {Big} from "big.js"
// test2.ts
import "./test"
Big(0) // no error as long as ./test is included
I'm at a loss here. I see "types": [] being recommended with other type libraries, but that advice does not seem to hold with the big.js typings.
Why should this issue be closed? It's still a problem.
The "types": [] workaround isn't working... :cry:
Hi @ManuelMolina97. Could you create a public repo containing a minimal setup that shows the issue so I could take a look?
@googol here's the minimal example: https://github.com/osdiab/big-global-types-issue
I think that the problem is export the definition globally in the main file. Looking at decimal.js code, they moved the global definitions to a specific file to prevent errors and keep the compatibility.
@googol I will open a PR doing the same. Can you take a look, please?
Most helpful comment
OK, so the advice to use
"types": []doesn't seem to work. I thought it might be some weird thing with my project, so I created a test project to confirm. I have made two observations thus far:"types": []does not seem to do anything with types frombig.jsTypings for
big.jsseem to pollute the global name space if I import it from within my own code:I'm at a loss here. I see
"types": []being recommended with other type libraries, but that advice does not seem to hold with thebig.jstypings.