HTML/C-like #include statements about typescript

[zilqarneyn]

This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)

It sure looks like most of your proposal is exactly a runtime feature. That’s essentially a non-starter here, and you’ll get a “go propose this as a JS feature and we’ll support it once it reaches Stage 3 of the TC39 Process”.

That confuses HTML/C includes (that are absolutely static, compile-time features), and JavaScript-style (AJAX/eval/etc., also known as "dynamic HTML" but such run-time code is not necessary nor any advantage here).

[MartinJohns]

This is out of scope for TypeScript. Anything that requires additional code to be emitted (beyond down-leveling and legacy features) is a no-go.

I've definitely seen a duplicate of this, but I can't find it right now. include is a too generic search term.

because tsc produces code with "require" statements (acceptable for Node.js, not for web browsers).

TypeScript does what it should do. If you're using modules, it needs to output module code. It doesn't have to be require, it can also be imports (which I think modern browsers understand now). It's up to your configuration.

edit: jcalz was faster. :(

[jcalz]

This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)

It sure looks like most of your proposal is exactly a runtime feature. That’s essentially a non-starter here, and you’ll get a “go propose this as a JS feature and we’ll support it once it reaches Stage 3 of the TC39 Process”.

[zilqarneyn]

This is out of scope for TypeScript. Anything that requires additional code to be emitted (beyond down-leveling and legacy features) is a no-go.

The term "C includes" may have suggested your comment, but there are no macro facilities (no macro expansion, thereoff) in TypeScript. Strictly for on-the-fly compile-time static analysis, informed by the included declaration files. That is, including is not for concatting files nor emitting something extra. Simply for declarations, & thereby, knowing/including the pre-existing library (such as Tone.js) is for informing TypeScript what the .TS file is referring to. Just for referencing, not emitting/concatting.

[IllusionMH]

Isn't that what /// <reference... > does?
https://www.typescriptlang.org/docs/handbook/triple-slash-directives.html#-reference-types-

Or approaches linked at the end of this section.

[RyanCavanaugh]

It sounds like you're just talking about a module bundler, of which many exist already. TS isn't a tool for doing that; it's a typechecker

[zilqarneyn]

Isn't that what /// <reference... > does? https://www.typescriptlang.org/docs/handbook/triple-slash-directives.html#-reference-types-

Or approaches linked at the end of this section.

They may sound similar, but they work differently/bizarrely, although extendable/debuggable (1) to include/refer/know both .d.ts files & .js libraries (without transforming either to any runtime-loadable file, maybe except (as already tsc seems to do) transforming .d.ts files to .js files when the including .ts file is module-based), (2) referrable from not only module/import/export based .ts files but also from other .ts files (& not converting them to module-based by emitting import/export statements into those non-module-based ones).

BTW, furthermore, <reference lib=.../> sounds like limited to only built-in (not user-defined) libxyz.d.ts files. The <reference path=.../> of TypeScript behaves bizarrely (when attempted to refer to a JS library, or in general). (1) I simply referred to Tone.js and then tsc told me that it is a .js file and I may use it with the --allowJS option, (2) when I did that then tsc told me that processing that file would overwrite the original file (& suggested hacking with tsconfig). Now, what is the sense of trying to compile/overwrite a referred file along with the referring file? If it were a .ts file, tsc would simply convert it to a .js file, but why? It should remain as is, & only included/referenced in compilation phase, for declarations/prototypes. Furthermore, when I simply rename Tone.js to Tone.ts, tsc trashes by dumping all of Tone.ts to the terminal/screen.

The way I suggest, seamlessly integrates all three of the types { (1) module-based .ts files, (2) global-scope .ts files that do not refer to any .js, (3) global-scope .ts files that refer to .js libraries }. Ironically, without this, a claim (or, two) that TypeScript loves to make, is/are actually (self-woundingly) very downgraded. One big claim is that, any JS is already TS, & that you may include TS extras little by little, at your own pace. However, until you convert your global-scope JS to module-based JS, that claim is irrelevant. (The other major claim is down-leveling things, despite refusing/disgracing the global-scope JS legacy almost completely. Where you cannot even set a foot, you cannot sell anything.)

One commenter suggested that "imports" has support from browsers, but the documentation at mozilla does not seem to list that ( https://developer.mozilla.org/en-US/search?q=Imports ), & therefore I do not know since when (if any) browser(s) started supporting it. Therefore, I prefer how I had factored a .js to two portions, to make one of them usable with modules/TypeScript.

[zilqarneyn]

It sounds like you're just talking about a module bundler, of which many exist already. TS isn't a tool for doing that; it's a typechecker

I do not use module-bundlers (at least, so far), & not asking TypeScript to "bundle" anything. Simply, while doing the type-checking of a .ts file, TS should know what declarations (functions/etc.) have been defined in other files.

[fatcerberus]

TS should know what declarations (functions/etc.) have been defined in other files.

It already does know that. It sounds like you have global declarations in files that TS is incorrectly treating as modules, which just means your project is configured incorrectly.

As for module (ESM import/export) support in browsers:
https://caniuse.com/?search=modules

Supported in Chrome and Safari since 2017 and Firefox since 2018.

[typescript-bot]

This issue has been marked as "Out of Scope" and has seen no recent activity. It has been automatically closed for house-keeping purposes.