Repository navigation
Turning off automatic loading of tsconfig.json #142
Description
Hi there!
My team is using tsify with Gulp to build a whole bunch of TypeScript files. We have a tsconfig.json file in our root to satisfy our editors, but we don't use it in our build system.
Up until tsify@0.15.5, that was okay, but with this update it seems like the plugin is now loading files from the tsconfig and our build system, which is bad. We've reverted to 0.14.8 as a result.
Is there an option to turn off consumption of tsconfig.json?
For reference, our tsconfig.json file looks like this:
{
"compilerOptions": {
"module": "commonjs",
"target": "ES5",
"moduleResolution": "node",
"experimentalDecorators": true,
"noEmitOnError": true
},
"files": [
"typings/main.d.ts",
"node_modules/app/common/core.ts",
"node_modules/app/client/main.ts",
"node_modules/app/server/main.ts"
]
}
Activity
hakatashi commentedon May 17, 2016
I also have this problem. I think the recent changes (like 0.15.2 or 0.15.5) about tsconfig.json are very breaking and should be released under major version...
iKBAHT commentedon May 19, 2016
Our project have many of bundles with different configs for typescript. It will be great if there are exist option to put any file as config, like this http://stackoverflow.com/a/34826930/964711
smrq commentedon May 19, 2016
@hakatashi I have reverted the changes in 0.15.5 and re-released under a major version bump.
@iKBAHT You can point to a different
tsconfig.jsonwith the--project another-tsconfig.jsonoption. (This is not called out explicitly in the README because it's a feature oftsc.)@LPGhatguy I appreciate the thoughtful writeup. It hadn't occurred to me that more closely supporting the features of the official TypeScript compiler would be a breaking change.
My thoughts in this post that apply here also: #143 (comment)
As far as I know, there is no way of preventing
tscfrom using atsconfig.jsonthat you have. I'm reluctant to throw in an extra option on top to make tsify behave differently than the official compiler.The one dissenting thought I have is that when using
tsc, you can specify files on the command line, which override thefilesandexcludeproperties of thetsconfig.jsonif you have them. But it seems to me that this is a less common case than just using tsconfig properly.What about your editor means you need a broken tsconfig?
(I'll also note that using
--projectto point to a valid tsconfig would suffice, even if you need another tsconfig to satisfy whatever it is about your editor.)LPGhatguy commentedon May 19, 2016
@smrq RE this thread & #143:
My
tsconfig.jsonis correct, but not a complete description of our compilation flow. The official compiler doesn't support glob file selection, which is one reason why we usetsifywith a tool like Gulp.I think that this decision should be okay for compilation targeted at the CLI, but for people using Browserify and
tsifyprogrammatically, this change ignores the explicit configuration from the user! The TypeScript API doesn't do this when accessed programmatically, which is the behavior I'm expecting when I pull in a TypeScript wrapper plugin for Browserify and use it programmatically.That being said, even just a flag to turn off automatic loading of
tsconfig.jsoninstead of having to create a faketsconfig.jsonwould be nice!smrq commentedon May 19, 2016
Re: globs, it might be worth keeping an eye on microsoft/TypeScript#5980. Incidentally, because tsify is now using TypeStrong/tsconfig for
tsconfig.jsonparsing, it already supports the non-standardfilesGlobproperty, so that might help out as well.Interesting consideration about the CLI vs. API. With Browserify, you don't get any distinction between the two as a plugin/transform author, so behaving differently depending on the context just isn't possible.
To be clear, are you referring to this API? Or something else?
LPGhatguy commentedon May 19, 2016
That API is the compiler API that I was thinking of.
Support
filesGlobis awesome, but our TypeScript editor plugins don't implement it D:Additionally, we use our build for a little bit of crazier stuff. In the typical application, we have three code locations:
clientservercommonclientandserverboth independently referencecommon, and because of the different environments they require different (and multiple!) compilation strategies. We reference all of their entry points fromtsconfig.jsonto make our editors happy, shielding it from the monstrosity defined via Gulp.This is a pretty darn specific use case, yeah, but just having a flag to turn off automatic consumption of
tsconfig.jsonwould go miles in complicated cases like that.garthk commentedon May 28, 2016
While specific, @LPGhatguy, your use case exactly matches mine. It's early in my project, so it makes a lot of sense to have client and server in the same repository.
tsfifydrags the server source into the client bundle. While I sympathise with @smrq's decision to prioritisetscconventions overbrowserify, the result is that I can't usetsifyand eagerly await a fork with the opposite priority.LPGhatguy commentedon Jun 14, 2016
Thanks for the feedback and input on this!
Has there been any decision making involving this sort of use of the project, @smrq, like a flag?
I can understand preserving the decision that's friendly to CLI users, but it almost certainly means that users with more complicated workflows will need to find another solution for TypeScript and Browserify.
LPGhatguy commentedon Jul 11, 2016
With the release of TypeScript 2.0 Beta (and tsify 1.0), I'm worried about diverging featuresets with this project.
Is there any possibility of a flag to turn off automatic
tsconfig.jsonloading?