Add the possibility to import Types from global loaded Librarys

🔍 Search Terms

import types global

✅ Viability Checklist

This wouldn't be a breaking change in existing TypeScript/JavaScript code
This wouldn't change the runtime behavior of existing JavaScript code
This could be implemented without emitting different JS based on the types of the expressions
This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

In browser environemnt you often need to load librarys, wich are developed as ESM modules ans with ESM types globaly, cause they are only delivered as CJS, for example typescript, see: #57010

There should be a way, so I can import typescript and use it, without loading the library (like import type), but there should be no error if I use instances from the import.

for example at the moment it is like this:

 import type ts form 'typescript'
 const a = ts.SyntaxKind.TaggedTemplateExpression

will error cause the import is only imported as type

maybe something like this:

 import global type ts form 'typescript'
 const a = ts.SyntaxKind.TaggedTemplateExpression

or

 import global ts form 'typescript'
 const a = ts.SyntaxKind.TaggedTemplateExpression

would be possible?

I don't understand what you're asking for. What makes this import "global" ? What's the emitted code supposed to be? If you have a CJS library, how are you loading it from a browser without using a bundler?

I’m guessing they’re loading the TS API globally (using a <script> tag) and want those globals to be visible at compile time, rather than resolving it as a module.

If so, then that was #53570, which we decided not to do.

I’m guessing they’re loading the TS API globally (using a <script> tag) and want those globals to be visible at compile time, rather than resolving it as a module.

I'm developing my application without using any bundler as a Project wich is using ESM modules. So I tried to imporrt typescript (or also other packages wich are only available as CJS), but it will fail. So I load these modules globaly (via a scrit tag in my main html file), but then I can not use the tyes in my ts file. This is the issue. I can then use "import type", but then I can use the import only as a type definition, but I also need to access objects from it. This will work at runtime since the file is loaded globally

I would love to only use ESM, but also TS is not available as a ESM build

I don't understand what you're asking for. What makes this import "global" ? What's the emitted code supposed to be? If you have a CJS library, how are you loading it from a browser without using a bundler?

the emitted code should be the same as with import type, remove the import, leave the rest.

what is the typescript npm packge? is it not CJS? I can load this directly via scrit tag in browser, and I can import it in vscode in my file, but the import will only work if I use a bundler

typescript.js creates a ts global and, if running in a CJS context, exports that. So what you need is just a .d.ts file that says

import typescript = require('typescript');

declare global {
    export import ts = typescript;
}

to represent that that's happening

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@RyanCavanaugh)

I get this error when I try this:

Is this now a question? Cause I can not get this to work, or is this an issue?

I guess one thing you could do is have a separate file like ts-globalizer.d.ts in your project that looks like this:

export * from "typescript";

export as namespace ts;

Though I guess that gives you this error...

Module '"typescript"' uses 'export =' and cannot be used with 'export *'.

Duh:

import typescript = require("typescript");
export = typescript;

export as namespace ts;

Playground Link

Will also not work:

Ryan Cavanaugh (@RyanCavanaugh)

It's a safety measure - there's allowUmdGlobalAccess to get around it. Ryan Cavanaugh (@RyanCavanaugh) has not tried to mow that one down in recent deprecations. 😄

Isn't then my suggestion a valid feature request?

To use a global JS library with type information, I need to create an extra file, create a bunch of code, add an compiler switch wich may be deprecated at some time...

It is, and we can keep it open - I just realistically don't know how much traction it will get, versus how much the cost is of adding new syntax and supporting it. The workaround isn't great, but it is possible and not a huge burden, and the number of secretly-global modules is going to get rarer.

Yeah, thanks for the solution. Already tested it, and works nicely.

Jochen Kühner (@jogibear9988)

Jochen Kühner (@jogibear9988) What about this one? Put it in a seperate .d.ts file.

import ts = require('typescript');

declare global {
    namespace globalThis {
        export { ts }
    }
}

import ts = require('typescript');

declare global {
    namespace globalThis {
        export { ts }
    }
}

Yeah, also works. And for me, easier to understand

Navigation Menu

Repository navigation

Add the possibility to import Types from global loaded Librarys #57019

🔍 Search Terms

✅ Viability Checklist

⭐ Suggestion

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add the possibility to import Types from global loaded Librarys #57019

Description

🔍 Search Terms

✅ Viability Checklist

⭐ Suggestion

Activity

RyanCavanaugh commented on Jan 11, 2024

fatcerberus commented on Jan 12, 2024

jakebailey commented on Jan 12, 2024

jogibear9988 commented on Jan 12, 2024

jogibear9988 commented on Jan 12, 2024

jogibear9988 commented on Jan 12, 2024

RyanCavanaugh commented on Jan 12, 2024

jogibear9988 commented on Jan 13, 2024

jogibear9988 commented on Jan 14, 2024

DanielRosenwasser commented on Jan 30, 2024

DanielRosenwasser commented on Jan 30, 2024

DanielRosenwasser commented on Jan 30, 2024

jogibear9988 commented on Jan 30, 2024

DanielRosenwasser commented on Jan 30, 2024

jogibear9988 commented on Jan 30, 2024

DanielRosenwasser commented on Jan 30, 2024

jogibear9988 commented on Jan 30, 2024

whzx5byb commented on Jan 31, 2024

jogibear9988 commented on Jan 31, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions