Typescript warning about "app" global variable

reinaldoams · July 24, 2024, 3:21pm

Hi, I’m using react4xp and I’m getting the typescript warn when using the “app” global variable “Cannot find name ‘app’.ts(2304)”.
How can I prevent that warning since the global variable exists and the code works properly?
Thank you

tom · July 26, 2024, 6:19am

Hi Reinaldo,

As usual the answer is “it depends”.

The easy answer

You can install "@enonic-types/global" from npm, and add it to types in tsconfig.json to get these global types.

My preferred approach…

I will usually create a types.ts file in each of my projects where I declare these types.

The reason I want to declare app myself, is that I want app.name to be a string literal (and not a string). That way I can use the string literal to build template strings.

E.g.

// types.ts
declare const app: {
  name: "com.myproject";
  version: string;
  config: { [key: string]: string };
};


// otherfile.ts
import type { Article } from "/site/content-types";

type ContentArticle = Content<Article, `${typeof app.name}:article`>;

// ----------------------

declare const content: ContentArticle;

// content.type = "com.myproject:article"

Happy coding!
– Tom Arild

reinaldoams · July 26, 2024, 2:29pm

Thank you for your response. But I already have @enonic-types/global installed and added to tsconfig.json and yet it’s not working.
Not only that happens for the “app” variable as I said, but also for the “log” variable, another global variable.

tom · July 29, 2024, 6:38am

@reinaldoams Can you share your tsconfig.json?

reinaldoams · July 29, 2024, 4:43pm

Sure! Here it is:

// This file is used by your code editor so it must be permissive to support
// * Enonic XP serverside files running on Nashorn
// * React4xp files running both on Graal-JS and in the browser
// * Potential assets running in the browser only
{ // https://www.typescriptlang.org/tsconfig
	"compilerOptions": {
		//──────────────────────────────────────────────────────────────────────
		// Modules
		//──────────────────────────────────────────────────────────────────────
		"allowUmdGlobalAccess": true,
		"baseUrl": ".",

		"paths": {
			"/lib/enonic/react4xp": ["node_modules/@enonic-types/lib-react4xp"],
			"/lib/xp/*": ["node_modules/@enonic-types/lib-*"],
			// So one can import local files using absolute path same as
			// * react4xp resolves during build time
			// * and Enonic XP resolves during runtime
			"/*": ["src/main/resources/*"], // For some reason this doesn't work in Visual Studio Code :(
		},

		// By default all visible ”@types” packages are included in your compilation.
		// Packages in node_modules/@types of any enclosing folder are considered visible.
		// For example, that means packages within ./node_modules/@types/,
		// ../node_modules/@types/, ../../node_modules/@types/, and so on.
		// If typeRoots is specified, only packages under typeRoots will be included.
		"typeRoots": [
			"node_modules/@types",
			"node_modules/@enonic-types"
		],

		// By default all visible ”@types” packages are included in your compilation.
		// Packages in node_modules/@types of any enclosing folder are considered visible.
		// For example, that means packages within ./node_modules/@types/,
		// ../node_modules/@types/, ../../node_modules/@types/, and so on.
		// If types is specified, only packages listed will be included in the global scope.
		// This feature differs from typeRoots in that it is about specifying only the exact
		// types you want included, whereas typeRoots supports saying you want particular folders.
		"types": [
			"@enonic-types/global", // No point, already added via typeRoots
			// "@enonic-types/lib-event" // No point, since it doesn't affect global scope
			// "@enonic-types/lib-react4xp"
		],

		//──────────────────────────────────────────────────────────────────────
		// Interop Constraints
		//──────────────────────────────────────────────────────────────────────
		"esModuleInterop": true, // Allow import React from 'react';

		//──────────────────────────────────────────────────────────────────────
		// Language and Environment
		//──────────────────────────────────────────────────────────────────────
		"jsx": "react", // Support jsx and tsx
		"lib": [
			// Keep in mind that DOM doesn't exist serverside, so only use it
			// in clientSide assets or pure clientSide React4xp components.
			"DOM",

			"ES2015"
		],

		//──────────────────────────────────────────────────────────────────────
		// Completeness
		//──────────────────────────────────────────────────────────────────────
		// Even though the setting disables type checking for d.ts files,
		// TypeScript still type checks the code you specifically
		// refer to in your application's source code.
		"skipLibCheck": true, // Disable type checking for node_modules
	},
	"include": [
		"src/main/resources/**/*.ts",
		"src/main/resources/**/*.tsx"
	]
}

tom · July 30, 2024, 6:35am

I can’t see anything wrong with your tsconfig-file. Sorry

But I think you probably don’t need "typeRoots", since libraries are associated with the correct types in "paths", and you add the global in "types".

– Tom Arild

Alan · August 1, 2024, 8:33am

Hi, I’m using react4xp and I’m getting the typescript warn when using the “app” global variable “Cannot find name ‘app’.ts(2304)”.

Can you post an example of your code which triggers the build warning?

reinaldoams · August 1, 2024, 12:11pm

It’s not a build warning. It’s a warning in the vs code editor.
I’m trying to access app in the .ts controller of parts, pages or in .ts files in the lib folder. Should be global and without any warning since the .tsconfig is configured for that.
Here is an example in a part controller:

const query = `type = "${app.name}:event"`,

In the app variable, I get

Cannot find name 'app'.ts(2304)

Alan · August 1, 2024, 1:07pm

What if you simply add an import of app and log like this:

import {app, log} from '@enonic-types/global';

I’ve tried it now and resolution of both variables worked fine for me, but I’m using IntelliJ.

reinaldoams · August 1, 2024, 1:53pm

If I try to do that, I get

File '(...)/xp/node_modules/@enonic-types/global/global.d.ts' is not a module.ts(2306)

Jonas · August 5, 2024, 7:04pm

VSCode is complaining that @enonic-types/global/global.d.ts' is not a module because the things you are trying to import are not exported.

If I add the export keyword to the declare const app statement in this file, the error message and red squiggly line go away.

I have no idea why IntelliJ is not complaining over this issue.

Edit: Managed to get VSCode to work properly without changing global.d.ts to a module. Steps:

enonic project create and choose the typescript starter.
Create a controller with a .ts-file referencing the global objects app and log.
Observe that VSCode reports the error (Cannot find name ‘app’):
Screenshot 2024-08-06 at 08.53.391290×444 39.8 KB
Run npm install in the project root directory.
Observe that the error is gone:
Screenshot 2024-08-06 at 08.47.131822×814 73.3 KB

Similarly, for React4XP:

enonic project create and choose the React4XP starter.
Edit the example controller at src/main/resources/site/parts/example/example.ts.
Observe that VSCode reports the error (Cannot find name ‘app’):

Screenshot 2024-08-06 at 09.09.131342×546 74.7 KB
Run npm install in the project root directory.
Remove lines 27-30 in tsconfig.json - the ones about typeRoot.
Observe that the error is gone:
Screenshot 2024-08-06 at 09.12.351824×1056 125 KB

Cwe · August 12, 2024, 8:41am

Yup, the import suggestion won’t work as the error message says, it’s not a module, it doesn’t export anything… It just modifies global scope.

Already been looking into that before the summer

github.com/enonic/xp

Make the global types importable

opened 12:09PM - 14 May 24 UTC

ComLock

LongTitle: Make the types in @enonic-types/global importable from @enonic-types/…core -- The types in @enonic-types/global are working as intended for Enonic XP server-side code files in src/main/resources/*.ts However when writing tests the global functions and object must be replaced by mocks. Since the globals are defined as "const" in @enonic-types/global, it's a type error if one tries to replace them. Changing the type to var (let) is not a good idea since that's actually wrong when it comes to the actual "runtime" types. My suggestion is to 1. export the global types in @enonic-types/core 2. make @enonic-types/global dependant on @enonic-types/core 3. import the global types from @enonic-types/core into @enonic-types/global and use them to define the const's Then if I need any of those global types anywhere, I can manually import only the specific ones I need from @enonic-types/core. One example is when implementing the classes in Mock-XP, I would like to use the type for the global log object as an interface: ``` import type {Log as LogInterface} from '@enonic-types/core'; export class Log implements LogInterface { public debug(...args: unknown[]): void { //... } } ``` The same goes then modifying the type of globalThis when mocking in test files: ``` import type {Log} from '@enonic-types/core'; declare module globalThis { let log: Log } log.debug = () => { // no-op silence :) } ``` I can probably make it even prettier with a local Global Type Library, or a local Global Modifying Module. But I need the actual types. I don't want to duplicate those types locally. Define once, use everywhere.

There is a workaround by using triple slash import

github.com

enonic/starter-ts/blob/master/src/jest/server/global.d.ts

/// <reference types="@enonic-types/global" />

export declare type App = typeof app;
export declare type Log = typeof log;
export declare type DoubleUnderscore = typeof __;
export declare type Require = typeof require;
export declare type Resolve = typeof resolve;

Cwe · August 15, 2024, 10:54am

With regards to the tsconfig.json file.

If one reads these two sections of the documentation:

It’s not entirely clear what happens if both typeRoots and types are defined at the same time.

–

Also keep in mind that Enonic globals such as app, log, etc only exists on the serverside.
In react4xp projects, server-side and “client-side” files can be in the same folder,
so setting up a perfect tsconfig.json file is impossible.

Either the Enonic Globals will be missing for both server and client, which is wrong for the server files.
Or the Enonic Globals will be present for both server and client, which is wrong for the client files…