My project is a 100% JavaScript application that operates in the browser, consisting of around 20 JS files with all function names in the global scope. Whenever I make changes to a JS file, I can simply refresh the page and see the updates immediately.
However, I am interested in incorporating static type checking into my project, which led me to explore TypeScript. By adding type annotations to variables and functions and setting module to none, I was able to seamlessly integrate TypeScript into my workflow. The TypeScript compiler (tsc) performs type checking on the .ts files and outputs the same .js files as before, allowing for hassle-free use in-browser without any modifications.
The issue arises when attempting to utilize a third-party library, such as pixi.js.
When trying to access properties like PIXI.settings.TARGET_FPMS, tsc raises an error stating Cannot find name 'PIXI'. I attempted to address this by including
/// <reference path="pixi.min.js"/>According to online resources, the recommended approach involves running npm install pixi.js followed by import * as PIXI from 'pixi.js'. However, opting for this method eliminates the ability to maintain the none module setting. Consequently, I would need to insert import and export statements throughout the codebase, resulting in emitted .js files with incompatible require or import statements geared towards Node.js rather than the browser. This, in turn, necessitates the use of tools like webpack to address these discrepancies, hinting at increased complexity in the project structure.
Is there a way for TypeScript to access the type information from pixi.js without resorting to extensive use of import/export/modules/webpack? Ideally, I aim to leverage tsc for type checking purposes while maintaining the current architecture of the application.
If all else fails, it appears that declaring var PIXI: any; within a file may serve as a viable workaround.