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

Making 'files' in 'tsconfig.json' optional #556

Closed
ghost opened this issue Jun 15, 2017 · 8 comments
Closed

Making 'files' in 'tsconfig.json' optional #556

ghost opened this issue Jun 15, 2017 · 8 comments

Comments

@ghost
Copy link

ghost commented Jun 15, 2017

Hi,

I'm implementing a system that packs a source directory that does not have a tsconfig.json, and therefore I need to point to a specific config file residing with the packer itself. Currently, it seems that this is not supported due to the path.join in findConfigFile. Could this behaviour be changed so that it can accept absolute paths? If so, would you accept a pull request?

Regards,
Sam

@johnnyreilly
Copy link
Member

@jbrantly what's your view on this? I seem to remember there being discussion around this in the past but I can't remember the conclusion...

@johnnyreilly
Copy link
Member

Related to #539 (as well as others no doubt)

@ghost
Copy link
Author

ghost commented Jun 15, 2017

Actually, now I come to think of it while working on it, the real issue I'm having is that files needs to be ignored, which is currently not possible. It throws the following error if I try to set it to an empty array, which is quite reasonable:

ERROR in /Users/samvv/Projects/engage2/proto2/packages/engagejs-platform/tsconfig.plugin.json
error TS18002: The 'files' list in config file 'tsconfig.json' is empty.

However, I know from the wiki that it should be possible, but I'm not sure how it would need to be translated to this project.

I might be wrong, but when I think about it, this seems more logical than providing yet another entry point in files, while the real the webpack config already contains the real entry point.

To sum it up: does files have any use in the context of a webpack loader? And if so, is there a way to get rid of it (or just ignore it/make it optional)?

@ghost ghost changed the title Specifying an absolute path for configFileName Makeing 'files' in 'tsconfig.json' optional Jun 15, 2017
@ghost ghost changed the title Makeing 'files' in 'tsconfig.json' optional Making 'files' in 'tsconfig.json' optional Jun 15, 2017
@ghost
Copy link
Author

ghost commented Jun 15, 2017

Maybe this is a bit out of the scope of this project, but if what I'm saying makes sense, I'd be willing to give it a try.

@johnnyreilly
Copy link
Member

johnnyreilly commented Jun 15, 2017

Why don't you simply not supply files rather than supplying an empty one? It's been a TypeScript compiler error to supply an empty files since TypeScript 2.1 (or thereabouts..)

@ghost
Copy link
Author

ghost commented Jun 15, 2017

Without a files object it defaults to fetching all the sources in the "current directory" of the custom tsconfig.json-file, which is the directory of the platform, not of the project I want my platform to compile 😕 That's why I said it might be out-of-scope, since it's not a very common use case.

@johnnyreilly
Copy link
Member

Does the configFileName option not give you what you need? https://github.com/TypeStrong/ts-loader/tree/f4d8e711b2193cec358f94adf92202f39b8b2473#configfilename-string-defaulttsconfigjson

BTW doesn't your setup lead to a rather problematic experience in your editor of choice? It won't know what the settings in your tsconfig.json are and may report different errors than your build system.

@ghost
Copy link
Author

ghost commented Jun 15, 2017

@johnnyreilly Not sure ... as I tried it with a patched version of ts-loader, it didn't work. And good point, I totally forgot about that! You're right, of course. Requiring a tsconfig.json solves it then. Thank you so much for pointing that out! I'll close this issue.

@ghost ghost closed this as completed Jun 15, 2017
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant