Is it really truly wrong to have an empty array for files in the config?

[danfuzz]

TypeScript Version: 2.1.4

Code

$ mkdir ts-error
$ cd ts-error
$ npm install typescript@2.1.4
$ echo '{"files": []}' > tsconfig.json
$ ./node_modules/.bin/tsc
error TS18002: The 'files' list in config file '/Users/danfuzz/testing/ts/tsconfig.json' is empty.

Expected behavior:

tsc doesn't complain about not actually getting asked to compile anything.

Actual behavior:

The error as noted.

Context:

It is of course pretty silly to actually use the TS compiler on the commandline and with an actual tsconfig.json in the way demo'ed here. However, in the case of using the ts-loader module to hook up the TS compiler to Webpack, this is how it sets itself up. (I'm just a user of ts-loader, not a developer of it, so please take this with a grain of salt.) AIUI ts-loader sets up the basic config with an empty files, and then makes separate calls to compile each file it's asked to, one at a time. This arrangement worked as of typescript version 2.0.10, but it broke as of 2.1.4.

I also filed TypeStrong/ts-loader#405 on ts-loader. It's not clear to me what the best way to address the issue is.

[danfuzz]

I understand that this change in behavior was intentional and for good reason, like, if you aren't intentionally asking not to compile anything, then it's probably bad if the compiler doesn't compile anything and also doesn't let you know.

So, by way of suggestion, maybe there can be an explicit config file flag that indicates "really, zero files are being listed intentionally."

[mhegazy]

We have added the error to avoid users calling the compiler with no input and wondering why they got no outputs.

tsloader calls the compiler API, it can change the config before passing it to the compiler.

[danfuzz]

it can change the config before passing it to the compiler.

But what can it change the config to in order to successfully tell TypeScript that it's okay that the config explicitly specifies zero files? Near as I can tell, there's nothing straightforward it can do to say that. (One workaround is to add a dummy entry to files.)

Adding a flag to that effect is the suggestion I made in the second comment on this bug, above.

[mhegazy]

add a single file that it is using? or ignore the errors? i have a made a similar change for ts-node: https://github.com/TypeStrong/ts-node/pull/226/files

[danfuzz]

In this case, there isn't actually any file at all (see original description). The config file is loaded (and specifies zero files), and then the resulting compiler is used to compile arbitrary individual files. Maybe ts-loader shouldn't be doing things that way, but before 2.1 it actually did demonstrably work.

[DanielRosenwasser]

So you're simply using TypeScript to verify your tsconfig.json?

[danfuzz]

Like I said before, I'm just a consumer of `ts-loader` who suddenly started seeing errors reported unexpectedly (with the version bump), and with only a basic understanding of how it's all hooked up. Please forgive my ignorance. Ultimately, that no-files config gets used / reused when actually compiling a file, but at the moment the compiler is instantiated, it doesn't have a list of files to compile, yet something *does* make a call to check the config file. You can see the code in question on the `ts-loader` bug I linked to. Thanks for looking into this.

[hilts-vaughan]

All my files are in filesGlob and am getting this error -- is there a way to silence this or at least check to make sure filesGlob OR files is not empty?

[DanielRosenwasser]

@hilts-vaughan why not use the include and exclude fields?

[hilts-vaughan]

Legacy reasons, mostly up until this point. Is filesGlob now deprecated? I don't see it here anymore: http://www.typescriptlang.org/docs/handbook/tsconfig-json.html

[hilts-vaughan]

It seems like it still does this even if include is non-empty.

[mhegazy]

fileGlobs was never a supported entry. It is an atom-typescript specific setting. Please share a tsconfig that is causing the message to show.

[DanielRosenwasser]

What I mean is that instead of using fileGlobs, use include. That way you won't get an error.

[aluanhaddad]

Also if you need to support filesGlob for some reason, you can still specify it in addition to include.

[SergeySagan]

Yet more who are requesting an option to disable this error when there are 0 files! Why the stubbornness? Just support what your users want! You are now forcing to use stupid workarounds, like having empty .ts files! http://stackoverflow.com/q/41211566/550975

[RyanCavanaugh]

I don't understand the use case? If you have zero files and you know you have zero files (in order to be in a position to specify the flag), why not just not invoke tsc ?

[DanielRosenwasser]

@RyanCavanaugh more recent context from @serjster here: #13656

[SergeySagan]

It is easier for us to just have all of our 30+ projects to have the same configs, we can automate such things, but having to deal with whether or not there are any ts files to only then have our automated azure builds run tsc is not practical, however because tsc failed our automated builds now fail as well. This change basically causes a bunch of our automated builds to fail! We have standardized templates that we use in all of our projects and this prevents us from using them...

[ketrex2]

I agree with much of the sentiment here. Consider another case: creating a new project and configuring typescript is often the first step for many teams. The notion that their initial project will throw an exception when no ts has been written yet is jarring. The absence of anything to compile shouldn't throw an exception, it should succeed with ease.

[jklmli]

Maybe this could be downgraded to a warning?

[oparisy]

Same issue as @serjster here: I'd prefer to keep an homogeneous config and not see some of my ICs fail due to this error. Keeping this behavior but providing a flag to demote this to a warning would definitely do the trick for me.

[cboden]

I have a repository specifying data structure types. I have a src folder with only .d.ts files and tsc compiles them all into a single .d.ts file which other repositories use. I have "src/**/*.d.ts" in my includes. When upgrading from TypeScript 2.0 to 2.1 this seems to be no longer valid.

The only work around I've found so far is to add a "blank.ts" file in src along with the rest of the .d.ts files and then add it to the files option in tsconfig to get it to compile.

[Casimodo72]

Hi, I'm trying out the Salsa language service in an ASP.NET MVC 5 project where everything is still JavaScript, but I enabled Salsa just to have IntelliSense for e.g. jQuery and Kendo via @types packages.
I added a tsconfig in order to exclude all the JavaScript libraries. I want the the language service to look only at my JS code and the TS definitions in @types.

So, in this IntelliSense-only scenario, the officially recommended way of making the compiler happy is to add an empty dummy file to the project because the "include" array must not be empty, right?
Or is there an other way to configure the language service just for IntelliSense without having to deal with such TS compiler issues?

[mhegazy]

So, in this IntelliSense-only scenario, the officially recommended way of making the compiler happy is to add an empty dummy file to the project because the "include" array must not be empty, right?

No. make sure the tsconfig.json content kind is None. this will avoid the Build from picking it up. Alternativelly you can set <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked> in your project file to avoid running the compilation all together.

In the next release of VS we will also add support for jsconfig.json to avoid this whole issue.

[Casimodo72]

@mhegazy : I followed your instructions and set the build action for tsconfig.json to "None" and added true to my project file.
However, the errors TS18003 and TS6129 still show up in Visual Studio's error list (with setting "Build + IntelliSense).
That strategy seems not to be a working for a pure IntelliSense scenario.

Anyway, I stopped my Salsa experiment and disabled it now. That's because I learned that it doesn't seem to understand my ES3 style JS "classes" in IIFE "namespaces" . So it gives me nice IntelliSense support for external libraries (via "d.ts" files), but removes support for my own JS code. I need IntelliSense for my own code more than for those external libraries, so the decision was easy.

[mhegazy]

@Casimodo72 these seems to be a few issues going on here. the error again means that the files were not picked. so I will need some additional info to debug the issue. can you share a project?

That's because I learned that it doesn't seem to understand my ES3 style JS "classes" in IIFE "namespaces" .

We are making some changes, to address some of these issues in #21974, if you can share a sample of the issues you are running into we can make sure we have them fixed.

[Casimodo72]

@mhegazy My experiment is located inside my current web project, so I can't share it. But you're welcome to look at it via team viewer or similar :-) The last time I tried it even didn't pick up the "index.d.ts" in @types folders for me. Maybe I was doing something fundamentally wrong.

My issue regarding "classes" and IIFE "namespaces":
If Salsa could understand the JS code generated in the TypeScript Playground (https://www.typescriptlang.org/play) that would be nice. Chose the "Using Inheritance" snippet and add a namespace around it and export "Animal".

The only difference to my scenario is that I'm writing:

"var fn = Animal.prototype;
fn.move = function"

instead of the playground's generated code:

"Animal.prototype.move = function"

But I could adapt to "Animal.prototype.move = function" if that would be supported by Salsa.
The older we get the more Salsa need , we will :-)

[Casimodo72]

@mhegazy Ok, I fixed my scenario and added the folder with my JS code to the list of "include".
Now only the JS "namespace" issue remains. Really hope this becomes supported someday.
Salsa is fun!

[mhegazy]

Please share a project we can use to diagnose the issue.

[RyanCavanaugh]

We'll be allowing zero-input compilations if a references array is present in tsconfig.json (even if it's empty)

[RyanCavanaugh]

See above comment - this behavior is now available in the nightly build / master branch

[Delagen]

@RyanCavanaugh When it will be in NPM?

[RyanCavanaugh]

@Delagen shipped with 3.0 on Monday

[Delagen]

@RyanCavanaugh seems still emit TS18003

[RyanCavanaugh]

Did you add the empty references array? If so can you post your entire tsconfig? Thanks!

[Delagen]

I supply empty include array.

[RyanCavanaugh]

Did you add the empty references array? If so can you post your entire tsconfig? Thanks!

[Delagen]

What is the references? I didn't find any tsconfig property with this name.

[RyanCavanaugh]

references appears at the top level:

{
    "compilerOptions": { /* ... */ },
    "references": []
}

[Delagen]

References is for separating projects from main entry. I want to disable load any files at start. And load its manually. When I use tsconfig.json with webpack all files from current directory included by default.

[ScottPeterJohnson]

AFAICT this works with empty include, but not empty files.

{
  "references": [],
  "include": []
}