Configuration For Treating JS/TS Files as Independent Units (modules)

[mjbvz]

From microsoft/vscode#16892

TypeScript Version: 2.2.1 / nightly (2.2.0-dev.201xxxxx)

Code
For a JavaScript project

jsconfig.json

{
    "compilerOptions": {
        "module": "commonjs",
        "allowSyntheticDefaultImports": false
    }
}

a.js

var foo = 'test'

b.js

var foo = 2

Expected behavior:
There should be a way to configure TypeScript to treat a.js and b.js as isolated units. That way, foo would have the type as defined in its file

Actual behavior:
The files are treated as a single unit. foo either has a string or number type in both files.

[mhegazy]

What do you mean single units? if these are modules, wold not they have at least one import or export? if they are not, why should they be "units"?

[mjbvz]

@mhegazy The request would be to treat all JavaScript files as modules by default, even if they do not follow the standard module conventions.

We've seen this type of issue few reported a few times, specifically when people are working on websites. Even though the JavaScript files may be be loaded on separate pages, as far as I know, there is no way to configure VScode to treat these files as independent modules, at least without making the files proper modules.

[DanielRosenwasser]

@mhegazy Mainly this is annoying for when you're going to write a module eventually, but TypeScript keeps bugging you.

@mjbvz, while I agree that this is annoying, how do you plan to surface it in VS Code? Do you believe there are no people writing global-style code in VSC? Is it possible that a different group of people would report the opposite issue?

[mjbvz]

@DanielRosenwasser I would see this being something that users can opt into by enabling another compiler option in the jsconfig.json

See microsoft/vscode#22011 for another manifestation of this issue. Users either need a way to opt into isolated files in a JS project, or we need to improve TypeScript's handling of multiple definitions of a symbol across multiple JS files

[mikl]

Is there any documentation on how to persuade TypeScript that a file is in fact a module? I have a file in a Node.js project where TS gives me these errors, despite the file having both imports and exports.

Edit: Nevermind, it was a strange issue in PhpStorm that was producing spurious errors from a file that turned out to be fine once PhpStorm was restarted.

[KostyaTretyak]

I like the idea with the config, but why only JavaScript files are mentioned here? What about TypeScript files?

[schl3ck]

Is there any progress to this issue?

It has the label Awaiting More Feedback, but I don't see any open questions?

In my opinion the best way to surface this is to provide another compiler option like @mjbvz already suggested.

[JacksonKearl]

Hitting this with two files that run in separate processes. I cant re-use names between the two, but they aren't technically modules.

[phudson]

I'm the author of the vscode issue @mjbvz refers to. I'd like to also request this feature - we have multiple JS files that run in the same application, use the same APIs, but are independent. I want a jsconfig.json to set options, but I do NOT want the files treated together, but independently.

[Gr3q]

Hitting this as well, now I can't even use export {}; as a workaround after an update because it gets included with es6 module resolution.

I'm working in an environment what has custom module resolution and I can't flag my files as independent units anymore.

[phudson]

"Custom module"? Pah, I don't even have modules. A set of independent files is all I have. Which is why this would be so useful

…

On Fri, 9 Oct 2020 at 20:09, Attila Greguss ***@***.***> wrote: Hitting this as well, now I can't even use export {}; as a workaround after an update because it gets included with es6 module resolution. I'm working in an environment what has custom module resolution and I can't flag my files as independent units anymore. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#14279 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADZSIPQWZQKAVHSF4CNQ3DSJ5NVXANCNFSM4DBK537A> .

[redradist]

I also faced with such need ... currently TypeScript enforce developer to add export {}; but it is agly crutch

[trafnar]

I also have this problem, I'm creating a project which has a series of typescript files, each of which represents a "userscript" (greasemonkey / tampermonkey script), so each file is totally independent, and also, is not a module.

The fact that I want to have these files all within one vscode project means I can't use the same variable names in any of them.

[esc-mhild]

Here yet another use-case in which this problem occurs: We have built a data-processing platform based on the Graal runtime (runs Javascript, C, Java, Python, ... in the same memory space) and author data-processing scripts in Typescript. Namespacing is, of course, an option but seems unnecessarily pedantic if any one script is only ever run by itself (what other posts call "in isolation", i.e., as the only script within in the scope of the runtime).

As a work-around, a trip down Memory Lane might do the trick: Have your build tool enclose the script in an anonymous function that is executed immediately. In Grunt, for example, using grunt-contrib-concat and grunt-contrib-copy like this:

concat : {
	'ts-hack' : {
		options : {
			banner : '(function(){\n\n',
			footer:  '\n\n})();'
		},
		files : [ {
			expand : true,
			cwd : 'src/main/ts',
			src : [ '**/*.ts' ],
			dest : 'target/ts'
		}]
	}
},
copy : {
	'ts-hack' : {
		files : [ {
			expand : true,
			cwd : 'src/main/ts',
			src : [ '**', '!**/*.ts' ],
			dest : 'target/ts'
		} ]
	}
}

In tsconfig.json:

"include": [
	"target/ts/**/*.ts"
], ...

[phudson]

Just got bitten by this AGAIN, where a function with the same name (and same functionality, as it happens) was defined in two files, one with a JSDoc for the parameters, one without (and so got typed as taking "any" parameter types).

An erroneous call to the function was written and not caught because VSCode found the "any" overload.

[phudson]

Can you explain how #47495 fixes this issue? I can't see it right now but I may be being dense.

What do I set to have each JS file (just JS, no modules in sight at all) considered in isolation?

[weswigham]

moduleDetection: force, optionally alongside isolatedModules: true.

[phudson]

How do I understand when / in which version this will happen? In the latest vscode, and in the typescript online doc, there doesn't seem to be support for "moduleDetection: force" still.

[reporter123]

Looks like Typescript 4.7 will introduce it that's the merge I saw. That version is in beta.

[ValeTheVioletMote]

Is there any workaround? iirc having export {} flags it to the browser as a module, which requires it to be imported as one, etc.

I guess the only other option would be to downgrade TSC to 3.9? We didn't have this bug then.

[DanielRosenwasser]

@ValeTheVioletMote I'm not sure what issues you might be having since the comment is sparse on details. If you're having an issue in a latest version of TS, it might be worth filing an issue with more detail; if not, a StackOverflow question might be a better direction.

[reporter123]

Typescript 4.7 appears to have been released now with the
"moduleDetection": "force" option.

Beyond that I don't think there's any other way.

[DanielRosenwasser]

You can read up on the the moduleDetection flag on our documentation. Most users coming to this issue are likely interested in the force option.

New issues should be filed separately.