Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
danfuzz opened this issue Dec 8, 2016 · 41 comments

Comments

Projects
None yet
@danfuzz
Copy link

commented Dec 8, 2016

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

This comment has been minimized.

Copy link
Author

commented Dec 8, 2016

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

This comment has been minimized.

Copy link

commented Dec 8, 2016

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

This comment has been minimized.

Copy link
Author

commented Dec 8, 2016

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

This comment has been minimized.

Copy link

commented Dec 8, 2016

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

This comment has been minimized.

Copy link
Author

commented Dec 8, 2016

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

This comment has been minimized.

Copy link
Member

commented Dec 8, 2016

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

@danfuzz

This comment has been minimized.

Copy link
Author

commented Dec 8, 2016

@hilts-vaughan

This comment has been minimized.

Copy link

commented Dec 23, 2016

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

This comment has been minimized.

Copy link
Member

commented Dec 23, 2016

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

@hilts-vaughan

This comment has been minimized.

Copy link

commented Dec 23, 2016

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

This comment has been minimized.

Copy link

commented Dec 23, 2016

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

@mhegazy

This comment has been minimized.

Copy link

commented Dec 23, 2016

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

This comment has been minimized.

Copy link
Member

commented Dec 24, 2016

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

@aluanhaddad

This comment has been minimized.

Copy link
Contributor

commented Dec 24, 2016

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

@Serjster

This comment has been minimized.

Copy link

commented Jan 25, 2017

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

This comment has been minimized.

Copy link
Member

commented Jan 25, 2017

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

This comment has been minimized.

Copy link
Member

commented Jan 25, 2017

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

@Serjster

This comment has been minimized.

Copy link

commented Jan 25, 2017

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...

@Ketrex

This comment has been minimized.

Copy link

commented Jan 25, 2017

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.

@jiaweihli

This comment has been minimized.

Copy link

commented Apr 19, 2017

Maybe this could be downgraded to a warning?

@oparisy

This comment has been minimized.

Copy link

commented May 5, 2017

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

This comment has been minimized.

Copy link

commented Jul 6, 2017

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

This comment has been minimized.

Copy link

commented Mar 2, 2018

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

This comment has been minimized.

Copy link

commented Mar 3, 2018

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

This comment has been minimized.

Copy link

commented Mar 6, 2018

@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

This comment has been minimized.

Copy link

commented Mar 6, 2018

@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

This comment has been minimized.

Copy link

commented Mar 10, 2018

@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

This comment has been minimized.

Copy link

commented Mar 10, 2018

@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

This comment has been minimized.

Copy link

commented Mar 30, 2018

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

@RyanCavanaugh RyanCavanaugh self-assigned this Apr 5, 2018

@RyanCavanaugh

This comment has been minimized.

Copy link
Member

commented Apr 5, 2018

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

@RyanCavanaugh RyanCavanaugh added the Fixed label Jun 26, 2018

@RyanCavanaugh

This comment has been minimized.

Copy link
Member

commented Jun 26, 2018

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

@Delagen

This comment has been minimized.

Copy link

commented Aug 1, 2018

@RyanCavanaugh When it will be in NPM?

@RyanCavanaugh

This comment has been minimized.

Copy link
Member

commented Aug 1, 2018

@Delagen shipped with 3.0 on Monday

@Delagen

This comment has been minimized.

Copy link

commented Aug 1, 2018

@RyanCavanaugh seems still emit TS18003

@RyanCavanaugh

This comment has been minimized.

Copy link
Member

commented Aug 1, 2018

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

@Delagen

This comment has been minimized.

Copy link

commented Aug 2, 2018

I supply empty include array.

@RyanCavanaugh

This comment has been minimized.

Copy link
Member

commented Aug 2, 2018

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

@Delagen

This comment has been minimized.

Copy link

commented Aug 5, 2018

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

@RyanCavanaugh

This comment has been minimized.

Copy link
Member

commented Aug 5, 2018

references appears at the top level:

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

This comment has been minimized.

Copy link

commented Aug 5, 2018

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

This comment has been minimized.

Copy link

commented Aug 5, 2018

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

{
  "references": [],
  "include": []
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.