Turning off automatic loading of tsconfig.json

[LPGhatguy]

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 [email protected], 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"
    ]
}

[hakatashi]

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]

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]

@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.json with the --project another-tsconfig.json option. (This is not called out explicitly in the README because it's a feature of tsc.)

@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 tsc from using a tsconfig.json that 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 the files and exclude properties of the tsconfig.json if 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 --project to point to a valid tsconfig would suffice, even if you need another tsconfig to satisfy whatever it is about your editor.)

[LPGhatguy]

@smrq RE this thread & #143:

My tsconfig.json is 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 use tsify with a tool like Gulp.

I think that this decision should be okay for compilation targeted at the CLI, but for people using Browserify and tsify programmatically, 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.json instead of having to create a fake tsconfig.json would be nice!

[smrq]

Re: globs, it might be worth keeping an eye on microsoft/TypeScript#5980. Incidentally, because tsify is now using TypeStrong/tsconfig for tsconfig.json parsing, it already supports the non-standard filesGlob property, 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.

The TypeScript API doesn't do this when accessed programmatically, which is the behavior I'm expecting

To be clear, are you referring to this API? Or something else?

[LPGhatguy]

That API is the compiler API that I was thinking of.

Support filesGlob is 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:

• client
• server
• common

client and server both independently reference common, and because of the different environments they require different (and multiple!) compilation strategies. We reference all of their entry points from tsconfig.json to 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.json would go miles in complicated cases like that.

[garthk]

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. tsfify drags the server source into the client bundle. While I sympathise with @smrq's decision to prioritise tsc conventions over browserify, the result is that I can't use tsify and eagerly await a fork with the opposite priority.

[LPGhatguy]

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]

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.json loading?