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
tsify 0.15.5 compiles all ts files even if they're not imported #143
I'm using browserify/tsify within a gulp file. It starts off by compiling some file passed from the command line - tsStartFile. Everything is fine with tsify 0.15.4. But with 0.15.5, instead of just starting with tsStartFile and working recursively outward through all imported .ts files, it seems to compile every single .ts file it can find beneath the starting directory. Aside from being inefficient, this can cause problems if you have non-compiling .ts fragments that you're working on in some subdirectory - you'll get a bunch of syntax errors and compilaton will stop. Right now I've just reverted to 0.15.4.
This might be the same issue as #142, which is a problem that my team ran into. The compiler is loading files according to tsconfig.jsonand the files specified in Gulp, which causes all sorts of problems.
I recognize this behavior may be counter-intuitive for some users, but that's how tsc works, which is why tsify now behaves this way.
Ultimately, there are two competing interpretations of which files to compile, one of which comes from the Browserify camp, and the other of which comes from the TypeScript camp. Browserify users expect the passed-in files and their dependencies to be used, and no others. TypeScript users expect the files and exclude configurations from tsconfig.json to be respected. Under this second interpretation, the files passed in represent only the entry point(s) to your program. This interpretation is critical when dealing with *.d.ts files -- they are not directly depended upon, but their inclusion in the compilation unit is necessary.
My goal is to provide as thin as possible a layer on top of the TypeScript compiler in order to enable the bundling of CommonJS dependencies that Browserify provides. To that end, I'm attempting to follow the conventions set by TypeScript rather than Browserify if there is a conflict.
Ultimately, if you have a tsconfig.json, I think it's important to respect its contents with this tool.
I reverted the changes and re-released with a major version bump because this was a breaking change for some users.
@azarus This is a pretty old issue and with TypeScript 2.0 and later the files, include and exclude options can be used together, so things are not as inflexible as they once were. Additionally, it's now easy to use multiple tsconfig.json files without duplication with the extends option - so you can use a config file with an empty files array for tsify and another config file for some other tool - e.g. for TSLint.
Activity
LPGhatguy commentedon May 17, 2016
Do you have a
tsconfig.jsonfile in the root of your project?thunderkid commentedon May 17, 2016
Yes. It's this:
LPGhatguy commentedon May 17, 2016
This might be the same issue as #142, which is a problem that my team ran into. The compiler is loading files according to
tsconfig.jsonand the files specified in Gulp, which causes all sorts of problems.thunderkid commentedon May 17, 2016
But I don't see where my
tsconfig.jsonis telling it to load any particulartsfiles.LPGhatguy commentedon May 18, 2016
By setting the
excludesetting, all files not in the exclude list are implicitly added and marked for compilation.smrq commentedon May 19, 2016
I recognize this behavior may be counter-intuitive for some users, but that's how
tscworks, which is why tsify now behaves this way.Ultimately, there are two competing interpretations of which files to compile, one of which comes from the Browserify camp, and the other of which comes from the TypeScript camp. Browserify users expect the passed-in files and their dependencies to be used, and no others. TypeScript users expect the
filesandexcludeconfigurations fromtsconfig.jsonto be respected. Under this second interpretation, the files passed in represent only the entry point(s) to your program. This interpretation is critical when dealing with *.d.ts files -- they are not directly depended upon, but their inclusion in the compilation unit is necessary.My goal is to provide as thin as possible a layer on top of the TypeScript compiler in order to enable the bundling of CommonJS dependencies that Browserify provides. To that end, I'm attempting to follow the conventions set by TypeScript rather than Browserify if there is a conflict.
Ultimately, if you have a
tsconfig.json, I think it's important to respect its contents with this tool.I reverted the changes and re-released with a major version bump because this was a breaking change for some users.
azarus commentedon Jul 14, 2017
Sigh.....
cartant commentedon Jul 15, 2017
@azarus This is a pretty old issue and with TypeScript 2.0 and later the
files,includeandexcludeoptions can be used together, so things are not as inflexible as they once were. Additionally, it's now easy to use multipletsconfig.jsonfiles without duplication with theextendsoption - so you can use a config file with an emptyfilesarray for tsify and another config file for some other tool - e.g. for TSLint.