You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
typescript v2.1.4 doesn't like empty files in config #405
In my project (https://github.com/danfuzz/quillex), I'm getting the error "error TS18002: The 'files' list in config file 'tsconfig.json' is empty." which I've tracked back to this. (Note: I currently work around this by pointing my project at an older version of typescript.)
If I add a dummy entry to the files list, then typescript stops complaining, and things seem to work as expected, e.g.:
I don't know if this is the best solution to the problem, nor if it causes some other problem that I just haven't noticed yet. For the record, totally removing the files binding causes a different error ("error TS18003: No inputs were found in config file 'tsconfig.json'. Specified 'include' paths were '["**/*"]' and 'exclude' paths were '["node_modules","bower_components","jspm_packages"]'.").
typescript has an explicit error code and message for a specified-but-empty files list, so I'm guessing the change in behavior is intentional.
Here's the salient part of the stacktrace where the error is thrown:
at getFileNames (.../node_modules/typescript/lib/typescript.js:64355:41)
at Object.parseJsonConfigFileContent (.../node_modules/typescript/lib/typescript.js:64304:18)
at Object.getConfigParseResult (.../node_modules/ts-loader/dist/config.js:70:38)
at Object.ensureTypeScriptInstance (.../node_modules/ts-loader/dist/instances.js:33:36)
at Object.loader (.../node_modules/ts-loader/dist/index.js:17:24)
Thanks for posting details of your workaround. That's interesting. That said; there's nothing really that we can usefully do about this - this is the behaviour of the TypeScript compiler as intended (and this is intended - raised an issue with team and had it confirmed)
I assume "nothing to do about this" doesn't actually mean that ts-loader will be left broken forever. Is my — admittedly gross — hack pretty much the best that can be done?
Well you can stay on TypeScript 2.0 but yes that's pretty much it I'm afraid. Ts-loader works on top of TypeScript and we don't intend to implement different behaviour than the compiler for the most part
(Yeah I get that. I'm not interested in pegging the project to an old version of the compiler.)
I think I'm confused, then. I don't think I'm using ts-loader in an unusual way; that is, I don't get what I'm doing that's different than other users of ts-loader. Like, what should I be doing differently if I want to use TS 2.1?
Just as a coda on this: I figured out what the salient difference is between my situation and other projects'. I'd be surprised if I'm the only one who runs into this, so if nothing else the following can serve as a heads-up.
My project is using TS because it includes the module parchmenthttps://github.com/quilljs/parchment, which is written in TS. Parchment is distributed via npm as a prebuilt JS bundle (built using Webpack) and also includes the original .ts files, but it doesn't include a tsconfig.json file in the npm package. I'm choosing to compile the .ts files (and not use the bundle) because I don't want to have a double layer of Webpack loaders (that is, I'm making my own unified bundle of all the client code). That's why I'm using ts-loader.
So, what ts-loader is getting pointed at is a .ts file which doesn't have a tsconfig.json anywhere around it. This means the getConfigFile() call in ts-loader/config.ts ends up falling through and returning that default one with an empty files list. And it looks to me like any time that that happens, the subsequent attempt to run compilation will fail.
What I can do to work around the problem is add a new tsconfig.json file as a peer to the node_modules directory where parchment lands. (I could also drop one in the parchment directory, but if I do that, I'd no longer be using a pristine package from the npm registry.)
Actually it's even worse: I don't use parchment directly. I use it because it's a dependency of quill (which isn't written in TS). So, if I have to stop getting Parchment from npm I also have to stop getting Quill from npm (or hand-patch its dependencies somehow).
I'm saying the above by way of advocacy: I actively like the fact that Parchment gives me a choice of whether or not to use the TS source, while still using npm.
I've just stumbled into this error as well, and reason was actually quite different. I passed full path to configFileName property, but it actually takes a name of the file. ts-loader applies tsconfig search logic similar to tsc. Funny thing that it worked quite well on linux and mac, but failed on windows.
Eons ago now, but this was the issue I encountered, difference being that I had in my webpack.config.js
In my case,
webpack configuration file was in [project directory]/config/dist.webpack.cjs and
typescript configuration file was in [project directory]/config/dist.tsconfig.json.
The following code was working for me.
Activity
danfuzz commentedon Dec 8, 2016
Here's the salient part of the stacktrace where the error is thrown:
johnnyreilly commentedon Dec 8, 2016
Hi @danfuzz,
Thanks for posting details of your workaround. That's interesting. That said; there's nothing really that we can usefully do about this - this is the behaviour of the TypeScript compiler as intended (and this is intended - raised an issue with team and had it confirmed)
danfuzz commentedon Dec 8, 2016
I assume "nothing to do about this" doesn't actually mean that
ts-loaderwill be left broken forever. Is my — admittedly gross — hack pretty much the best that can be done?johnnyreilly commentedon Dec 8, 2016
microsoft/TypeScript#11834
johnnyreilly commentedon Dec 8, 2016
Well you can stay on TypeScript 2.0 but yes that's pretty much it I'm afraid. Ts-loader works on top of TypeScript and we don't intend to implement different behaviour than the compiler for the most part
johnnyreilly commentedon Dec 8, 2016
(not because we want to be difficult but that way pain lies - if not immediately then soon)
danfuzz commentedon Dec 8, 2016
(Yeah I get that. I'm not interested in pegging the project to an old version of the compiler.)
I think I'm confused, then. I don't think I'm using
ts-loaderin an unusual way; that is, I don't get what I'm doing that's different than other users ofts-loader. Like, what should I be doing differently if I want to use TS 2.1?FWIW, here's where I config
ts-loaderin my code: https://github.com/danfuzz/quillex/blob/master/server/ClientBundle.js#L93danfuzz commentedon Dec 8, 2016
In any case, thanks for the replies and the info.
johnnyreilly commentedon Dec 8, 2016
No problem. For what it's worth it's totally normal to not specify files at all. See this example: https://github.com/johnnyreilly/proverb-signalr-react/blob/master/tsconfig.json
danfuzz commentedon Dec 8, 2016
Just as a coda on this: I figured out what the salient difference is between my situation and other projects'. I'd be surprised if I'm the only one who runs into this, so if nothing else the following can serve as a heads-up.
My project is using TS because it includes the module
parchmenthttps://github.com/quilljs/parchment, which is written in TS. Parchment is distributed via npm as a prebuilt JS bundle (built using Webpack) and also includes the original.tsfiles, but it doesn't include atsconfig.jsonfile in the npm package. I'm choosing to compile the.tsfiles (and not use the bundle) because I don't want to have a double layer of Webpack loaders (that is, I'm making my own unified bundle of all the client code). That's why I'm usingts-loader.So, what
ts-loaderis getting pointed at is a.tsfile which doesn't have atsconfig.jsonanywhere around it. This means thegetConfigFile()call ints-loader/config.tsends up falling through and returning that default one with an emptyfileslist. And it looks to me like any time that that happens, the subsequent attempt to run compilation will fail.What I can do to work around the problem is add a new
tsconfig.jsonfile as a peer to thenode_modulesdirectory whereparchmentlands. (I could also drop one in theparchmentdirectory, but if I do that, I'd no longer be using a pristine package from the npm registry.)johnnyreilly commentedon Dec 8, 2016
FWIW - it's not advised to ship TS in
node_modules- ts-loader actually warns about this now: #399danfuzz commentedon Dec 8, 2016
Huh, well that's a bummer too, because ideally I'd love to keep referring to
parchmentvia npm and not have to e.g. pull in its git repo.danfuzz commentedon Dec 8, 2016
Actually it's even worse: I don't use
parchmentdirectly. I use it because it's a dependency ofquill(which isn't written in TS). So, if I have to stop getting Parchment from npm I also have to stop getting Quill from npm (or hand-patch its dependencies somehow).danfuzz commentedon Dec 8, 2016
I'm saying the above by way of advocacy: I actively like the fact that Parchment gives me a choice of whether or not to use the TS source, while still using npm.
13 remaining items
univerio commentedon Jan 10, 2018
I ran into the same, but in my case my
tsconfig.jsonwas in a different directory than the project root, so while a relative path doesn't work:an absolute path works just fine:
danfuzz commentedon Jun 26, 2018
BTW the underlying TS issue was just closed as "fixed," and looks like it will be released with TS 3.0: microsoft/TypeScript#12762 (comment)
a-x- commentedon May 15, 2020
I even had a typo in config file name.
Please, make this error more informative!
Really, what the
files, if config file even does not exist.FIX Explicitly mention tsconfig file in webpack.config.js to avoid `e…
Volmarg commentedon Jul 12, 2020
So i had the same issue, but actually non of the solutions were working. Spent couple hours on fixing it.
So my case:
Symfony 4.4 + Webpack-encore
ts-loader:npm install --save-dev ts-loader@3.5.0tsconfig.jsonin the same dir wherewebpack.config.jsis. In my case root./webpack.config.jstsconfig.jsOn the moment of writing this i only know how to include single files, there must be way to add scan of dir but for now it's ok`
Tip
.ts, but.jsis working also for meAdd TypeScript support (#5027)
newdaveespionage commentedon Sep 9, 2020
Eons ago now, but this was the issue I encountered, difference being that I had in my
webpack.config.jsWhen what
ts-loaderwanted wasjoshverd commentedon Sep 16, 2020
I fixed this issue by adding
__dirnamebefore the config file's name:Add TypeScript support (getredash#5027)
lpender commentedon Apr 8, 2021
I ultimately solved this only by upgrading to webpack 5
JeukHwang commentedon Aug 7, 2022
In my case,
webpack configuration file was in
[project directory]/config/dist.webpack.cjsandtypescript configuration file was in
[project directory]/config/dist.tsconfig.json.The following code was working for me.
Redash development history in a single commit (#1)
Redash development history in a single commit (#2)
Squashed Redash development history (#1)