support globs in tsconfig.json files property (or just file/directory exclusions) #1927

Closed
JeroMiya opened this Issue Feb 4, 2015 · 108 comments

Comments

Projects
None yet
@JeroMiya

JeroMiya commented Feb 4, 2015

An extension to #1692

Our ts project uses a grunt-based build system, with bower dependencies for the application and node_modules for build-tools. We will need the ability to exclude node_modules and bower_components from the build by default (unless files are referenced via /// ).

This causes an issue: we have end-to-end tests running in protractor, as well as unit tests running in jasmine, and unless we have the ability to exclude node_modules and bower_components, both will be parsed and we'll get duplicate definition errors.

In Visual Studio today, this is why we need to exclude both bower_components and node_modules from the project, because visual studio automatically parses all files in the project with no way to exclude them except to keep them out of the project altogether.

A number of third party tools have started to support tsconfig.json, and one thing I've noticed is that most of them support some sort of extension to tsconfig.json that supports file globs. I propose we just add support into the spec for file globs. For the version of typescript on npm, we can just depend on the appropriate file glob libraries in the npm ecosystem. For the Visual Studio embedded version of TypeScript, just embed the glob libraries that are needed statically in the installation.

As a fallback, if the notion of including a third party glob library is a non-starter, then the following fallback supporting a subset of the glob patterns would solve our problem at least partially.

Fallback:
Support both file and directory inclusions and exclusions in the files property:

files: [
  'app/', (equivalent to 'app/**/*.ts')
  '!e2e/', (equivalent to '!e2e/**/*.ts')
  '!node_modules/',
  '!app/bower_components/',
  '!app/vendor/fooLib/fooLib.ts'
]

@danquirk danquirk added the Suggestion label Feb 4, 2015

@danquirk

This comment has been minimized.

Show comment
Hide comment
@danquirk

danquirk Feb 4, 2015

Member

We certainly talked about this for awhile. See Anders' comment here for one large concern: #1692 (comment)

Member

danquirk commented Feb 4, 2015

We certainly talked about this for awhile. See Anders' comment here for one large concern: #1692 (comment)

@JeroMiya

This comment has been minimized.

Show comment
Hide comment
@JeroMiya

JeroMiya Feb 4, 2015

Yes, I've read that comment. Unfortunately, for larger and more complicated projects, the lack of these glob and exclusion patterns makes it impossible to use tsconfig.json at all. If editors support tsconfig.json, we would end up having to disable it due to various errors in mismatched configuration between e2e, unit tests, and the application. And, if the editor uses tsconfig.json to configure compile-on-save and auto-complete in a standard way (and doesn't support a way to override this in a custom project file format, or extension to tsconfig.json as is the case with atom-typescript for example), then we've lost all of that functionality as well.

Globs and exclusion patterns are just how large typescript projects are made managable. We manage it now with build tools like grunt and gulp which support globs and exclusions, but so far the editors and IDEs haven't been configurable in the same way, leading to messy workarounds. For example, in visual studio we have to exclude all the end to end tests from the main app project so it doesn't parse them and complain about duplicate identifiers. We then have a separate visual studio project which just includes the end to end tests. We should be doing the same thing with unit tests, but we decided not having jasmine type declarations visible from the application code was not worth creating a separate unit test project. I would rather edit files in the project all at once, like I would do in Sublime or Atom or Brackets.

JeroMiya commented Feb 4, 2015

Yes, I've read that comment. Unfortunately, for larger and more complicated projects, the lack of these glob and exclusion patterns makes it impossible to use tsconfig.json at all. If editors support tsconfig.json, we would end up having to disable it due to various errors in mismatched configuration between e2e, unit tests, and the application. And, if the editor uses tsconfig.json to configure compile-on-save and auto-complete in a standard way (and doesn't support a way to override this in a custom project file format, or extension to tsconfig.json as is the case with atom-typescript for example), then we've lost all of that functionality as well.

Globs and exclusion patterns are just how large typescript projects are made managable. We manage it now with build tools like grunt and gulp which support globs and exclusions, but so far the editors and IDEs haven't been configurable in the same way, leading to messy workarounds. For example, in visual studio we have to exclude all the end to end tests from the main app project so it doesn't parse them and complain about duplicate identifiers. We then have a separate visual studio project which just includes the end to end tests. We should be doing the same thing with unit tests, but we decided not having jasmine type declarations visible from the application code was not worth creating a separate unit test project. I would rather edit files in the project all at once, like I would do in Sublime or Atom or Brackets.

@NoelAbrahams

This comment has been minimized.

Show comment
Hide comment
@NoelAbrahams

NoelAbrahams Feb 5, 2015

@JeroMiya, perhaps the real problem here is how the projects are organised. I would consider moving the tests (both unit and end-to-end) to a separate project(s). IMO it's a better practice to keep tests and application code separate.

@JeroMiya, perhaps the real problem here is how the projects are organised. I would consider moving the tests (both unit and end-to-end) to a separate project(s). IMO it's a better practice to keep tests and application code separate.

@JeroMiya

This comment has been minimized.

Show comment
Hide comment
@JeroMiya

JeroMiya Feb 5, 2015

There are many style guides out there advocating for grouping files by feature. We've tried it both ways and find that grouping things by feature instead of by file type helps you be more productive, especially for larger projects with hundreds of features. You tend to work on a particular feature at a time, and it's a real pain to track down all the files related to that feature when they're spread out across multiple root directories. This way also encourages developers to write unit and end to end tests at the same time as changes to the code. I highly recommend it over keeping test code separate from the application code.

Regardless, as a compiler, TypeScript should not be opinionated about project file organization.

JeroMiya commented Feb 5, 2015

There are many style guides out there advocating for grouping files by feature. We've tried it both ways and find that grouping things by feature instead of by file type helps you be more productive, especially for larger projects with hundreds of features. You tend to work on a particular feature at a time, and it's a real pain to track down all the files related to that feature when they're spread out across multiple root directories. This way also encourages developers to write unit and end to end tests at the same time as changes to the code. I highly recommend it over keeping test code separate from the application code.

Regardless, as a compiler, TypeScript should not be opinionated about project file organization.

@NoelAbrahams

This comment has been minimized.

Show comment
Hide comment
@NoelAbrahams

NoelAbrahams Feb 5, 2015

Fair enough. We tried the grouping files by feature before moving the test cases out. Having test code in the same place as application code made it difficult to prototype features, because a lot of time was spent fixing compilation errors in the test cases.

Fair enough. We tried the grouping files by feature before moving the test cases out. Having test code in the same place as application code made it difficult to prototype features, because a lot of time was spent fixing compilation errors in the test cases.

@basarat

This comment has been minimized.

Show comment
Hide comment
@basarat

basarat Feb 11, 2015

Contributor

FWIW atom-typescript supports filesGlob as an optional extension to files. See spec.

Contributor

basarat commented Feb 11, 2015

FWIW atom-typescript supports filesGlob as an optional extension to files. See spec.

@NoelAbrahams

This comment has been minimized.

Show comment
Hide comment
@NoelAbrahams

NoelAbrahams Feb 11, 2015

@basarat,

    "filesGlob": [
        "./**/*.ts",
        "!node_modules/**/*.ts"
    ]

That looks like a nice feature, because it actually plays well with "files". I wonder what the objection from the TS team is to including this.

Perhaps the argument is: One cannot post the tsconfig to someone else to say "Hey, here's a description of all the files in my project".

Edit (after morning tea)

quote from @ahejlsberg

(1) Let me drop an empty tsconfig.json file in a directory and have everything in there be a project, and (2) let me describe the exact list of files I want included. The current design covers both with a minimum of complexity. That said, I can certainly see how an "exclude" list could be useful, although I suspect we'd then need globbing as well, so the level of complexity goes up. I definitely don't want this growing into an alternate build system. The intent is more to offer tools (e.g. editors) a simple and deterministic way to decide what the compilation context for a particular file is.

@basarat,

    "filesGlob": [
        "./**/*.ts",
        "!node_modules/**/*.ts"
    ]

That looks like a nice feature, because it actually plays well with "files". I wonder what the objection from the TS team is to including this.

Perhaps the argument is: One cannot post the tsconfig to someone else to say "Hey, here's a description of all the files in my project".

Edit (after morning tea)

quote from @ahejlsberg

(1) Let me drop an empty tsconfig.json file in a directory and have everything in there be a project, and (2) let me describe the exact list of files I want included. The current design covers both with a minimum of complexity. That said, I can certainly see how an "exclude" list could be useful, although I suspect we'd then need globbing as well, so the level of complexity goes up. I definitely don't want this growing into an alternate build system. The intent is more to offer tools (e.g. editors) a simple and deterministic way to decide what the compilation context for a particular file is.

@basarat

This comment has been minimized.

Show comment
Hide comment
@basarat

basarat Feb 11, 2015

Contributor

Just a note: whenever atom-typescript reads a file with filesGlob it expands the files in 'tsconfig.json' file so that people that are not using atom-ts will still get the correct list of files.

Contributor

basarat commented Feb 11, 2015

Just a note: whenever atom-typescript reads a file with filesGlob it expands the files in 'tsconfig.json' file so that people that are not using atom-ts will still get the correct list of files.

@rcollette

This comment has been minimized.

Show comment
Hide comment
@rcollette

rcollette Mar 5, 2015

+1
Globs are so common in use now. There could be .ts files in bower components under my project which have already been compiled to js and may have been done with a different release of TS so I wouldn't want them recompiling. I guess exclusion would handle the case but it just seems like once you support globs you won't need anything else.

I think leaving this up to an IDE to edit, like atom-typescript, is a bad idea. You're basically asking every IDE to implement the logic to keep the tsconfig.json file up to date.

+1
Globs are so common in use now. There could be .ts files in bower components under my project which have already been compiled to js and may have been done with a different release of TS so I wouldn't want them recompiling. I guess exclusion would handle the case but it just seems like once you support globs you won't need anything else.

I think leaving this up to an IDE to edit, like atom-typescript, is a bad idea. You're basically asking every IDE to implement the logic to keep the tsconfig.json file up to date.

@bidiboom

This comment has been minimized.

Show comment
Hide comment
@bidiboom

bidiboom Apr 3, 2015

I'm in the same case as @JeroMiya , complexe project (e2e, unit test and project code). The outDir option is really good to this kind of project so we can cleanly separate our TS code from the produce code : no accidental JS code modification by the team for example. And this glob option is almost mandatory for our kind of project due the number of file. Thanks to Gulp, we can handle this point but it can be really good to have this glob supported by the tscong file

bidiboom commented Apr 3, 2015

I'm in the same case as @JeroMiya , complexe project (e2e, unit test and project code). The outDir option is really good to this kind of project so we can cleanly separate our TS code from the produce code : no accidental JS code modification by the team for example. And this glob option is almost mandatory for our kind of project due the number of file. Thanks to Gulp, we can handle this point but it can be really good to have this glob supported by the tscong file

@panuhorsmalahti

This comment has been minimized.

Show comment
Hide comment
@panuhorsmalahti

panuhorsmalahti Apr 7, 2015

Globs are definitely needed. I don't see how I could manage the complex, multi-package TypeScript-based platform at work without globbing. Referencing every file by hand would be madness and require large amount of unnecessary work.

Globbing is especially useful when working with npm. I can depend on a npm package (which includes the type definitions), and then glob them in without knowing about the internals of that package.

Using the current setup in our project I can simply build package A, which consists of multiple modules, then require it from package B and glob the type definitions without any manual work even if the file structure of package A changes.

In theory the package A could output a single type definition file, but this is not supported by TypeScript, as each module of package A will create it's on .d.ts file. I already had to do a bit magic by writing a sort of "compiler" to make the .d.ts files ambient external declaration files automatically.

Globs are definitely needed. I don't see how I could manage the complex, multi-package TypeScript-based platform at work without globbing. Referencing every file by hand would be madness and require large amount of unnecessary work.

Globbing is especially useful when working with npm. I can depend on a npm package (which includes the type definitions), and then glob them in without knowing about the internals of that package.

Using the current setup in our project I can simply build package A, which consists of multiple modules, then require it from package B and glob the type definitions without any manual work even if the file structure of package A changes.

In theory the package A could output a single type definition file, but this is not supported by TypeScript, as each module of package A will create it's on .d.ts file. I already had to do a bit magic by writing a sort of "compiler" to make the .d.ts files ambient external declaration files automatically.

@beytu beytu referenced this issue in Microsoft/TypeScript-Sublime-Plugin Apr 15, 2015

Open

Inner project customization ? #144

@park9140

This comment has been minimized.

Show comment
Hide comment
@park9140

park9140 Apr 18, 2015

Contributor

@ahejlsberg, @basarat, a few thoughts on this.

One major issue with, .net projects in general, is with source control systems and project files. By inserting a file reference into your project file every time a new file is added to a folder you end up with additional and unnecessary churn in your repository.

On larger projects with multiple teams working on them you constantly end up with conflicting changes to files like tsconfig. As such in addition to unnecessary file churn we now have additional labor to manually merge changes to a file that could be automatically handled.

Contributor

park9140 commented Apr 18, 2015

@ahejlsberg, @basarat, a few thoughts on this.

One major issue with, .net projects in general, is with source control systems and project files. By inserting a file reference into your project file every time a new file is added to a folder you end up with additional and unnecessary churn in your repository.

On larger projects with multiple teams working on them you constantly end up with conflicting changes to files like tsconfig. As such in addition to unnecessary file churn we now have additional labor to manually merge changes to a file that could be automatically handled.

@basarat

This comment has been minimized.

Show comment
Hide comment
@basarat

basarat Apr 18, 2015

Contributor

As such in addition to unnecessary file churn we now have additional labor to manually merge changes to a file that could be automatically handled.

Agreed and would be great to have filesGlob supported.

FWIW If its a merge commit just delete the files section and let atom-typescript regenerate it for you. If its a rebase I chose "keep both" at each level ;). YMMV. Definitely needs glob support.

Contributor

basarat commented Apr 18, 2015

As such in addition to unnecessary file churn we now have additional labor to manually merge changes to a file that could be automatically handled.

Agreed and would be great to have filesGlob supported.

FWIW If its a merge commit just delete the files section and let atom-typescript regenerate it for you. If its a rebase I chose "keep both" at each level ;). YMMV. Definitely needs glob support.

@mhegazy

This comment has been minimized.

Show comment
Hide comment
@mhegazy

mhegazy Apr 18, 2015

Contributor

We would be open to taking a PR for excludes folders.

Our problem with globs is the complexity to support it, and we usually do not like to take dependencies on other packages as it limits our interoperability and system-independence. Having said so I think it is an important feature and indead does add value. Would be open to proposals here.

Contributor

mhegazy commented Apr 18, 2015

We would be open to taking a PR for excludes folders.

Our problem with globs is the complexity to support it, and we usually do not like to take dependencies on other packages as it limits our interoperability and system-independence. Having said so I think it is an important feature and indead does add value. Would be open to proposals here.

@basarat

This comment has been minimized.

Show comment
Hide comment
@basarat

basarat Apr 18, 2015

Contributor

So no for stuff like : https://github.com/aspnet/Home/wiki/Project.json-file#sources ?

FWIW I don't have a big issue with the workaround we've managed :). An updating project file isn't a problem new or annoying to me personally.

Contributor

basarat commented Apr 18, 2015

So no for stuff like : https://github.com/aspnet/Home/wiki/Project.json-file#sources ?

FWIW I don't have a big issue with the workaround we've managed :). An updating project file isn't a problem new or annoying to me personally.

@johnpapa

This comment has been minimized.

Show comment
Hide comment
@johnpapa

johnpapa Apr 22, 2015

tldr; Wow, we need this to support glob patterns.

Here is my use case ... I have a project with a few 100 files in TS and several 3rd party libraries with a concatenated lib.d.ts file. I want intellisense everywhere with the least amount of friction.

Option 1) Add /// reference to every file to point to the lib.d.ts and leave the tsconfig's file array undefined so it reads all of my app TS. Downside ... every file has this extra line ... yuk (100's of places)

Option 2) Add a gulp task that creates the files array in the tsconfig.json with the 3rd party lib.d.ts and my .ts files (lots of them). Downside, a gulp task to keep up, but at least my code is untouched

Option 3) Add glob support to tsconfig's files array so I can do this

files: ['lib.d.ts', '**/*.ts`]

I vote for option 3. So much easier and less friction for devs.

tldr; Wow, we need this to support glob patterns.

Here is my use case ... I have a project with a few 100 files in TS and several 3rd party libraries with a concatenated lib.d.ts file. I want intellisense everywhere with the least amount of friction.

Option 1) Add /// reference to every file to point to the lib.d.ts and leave the tsconfig's file array undefined so it reads all of my app TS. Downside ... every file has this extra line ... yuk (100's of places)

Option 2) Add a gulp task that creates the files array in the tsconfig.json with the 3rd party lib.d.ts and my .ts files (lots of them). Downside, a gulp task to keep up, but at least my code is untouched

Option 3) Add glob support to tsconfig's files array so I can do this

files: ['lib.d.ts', '**/*.ts`]

I vote for option 3. So much easier and less friction for devs.

@dmorosinotto

This comment has been minimized.

Show comment
Hide comment
@dmorosinotto

dmorosinotto Apr 24, 2015

+1 for globs in files with syntax for exclusion
files: ["lib.d.ts", "**/*.ts", "!node_modules/**/*.ts"]

+1 for globs in files with syntax for exclusion
files: ["lib.d.ts", "**/*.ts", "!node_modules/**/*.ts"]

@elishnevsky

This comment has been minimized.

Show comment
Hide comment
@elishnevsky

elishnevsky May 13, 2015

I see this issue is still open. Is support for glob patterns in tsconfig.json still being considered? That would make so many developers happy.

I see this issue is still open. Is support for glob patterns in tsconfig.json still being considered? That would make so many developers happy.

@CyrusNajmabadi

This comment has been minimized.

Show comment
Hide comment
@CyrusNajmabadi

CyrusNajmabadi May 13, 2015

Contributor

Is there a standard file-globbing specification anywhere? If we do this, we'll need to ensure that the globbing works the same on unix/windows, and that likely means writing the code to understand it ourselves.

Contributor

CyrusNajmabadi commented May 13, 2015

Is there a standard file-globbing specification anywhere? If we do this, we'll need to ensure that the globbing works the same on unix/windows, and that likely means writing the code to understand it ourselves.

@danquirk

This comment has been minimized.

Show comment
Hide comment
@danquirk

danquirk May 13, 2015

Member

Ideally we could just use some existing thing like https://www.npmjs.com/package/glob rather than rolling our own :(

Member

danquirk commented May 13, 2015

Ideally we could just use some existing thing like https://www.npmjs.com/package/glob rather than rolling our own :(

@CyrusNajmabadi

This comment has been minimized.

Show comment
Hide comment
@CyrusNajmabadi

CyrusNajmabadi May 13, 2015

Contributor

Ideally. But can we use such packages from tsc.exe where we don't have access to node packages?

Contributor

CyrusNajmabadi commented May 13, 2015

Ideally. But can we use such packages from tsc.exe where we don't have access to node packages?

@ahejlsberg

This comment has been minimized.

Show comment
Hide comment
@ahejlsberg

ahejlsberg May 13, 2015

Member

Right, the issue is that tsc.exe and the VS language service aren't in a position to take a dependency on node.js and therefore we can't use the node.js glob package. My feeling is that our best option so far is what is suggested in #3043: An exclude property in tsconfig.json that specifies a list of files and folders to exclude when a files list isn't explicitly specified. The net effect is the same as globbing with the list ["**/*.ts"] followed by a bunch of excludes. For example

{
    exclude: ["node_modules", "tests"]
}

would be equivalent to the globbing pattern ["**/*.ts", "!node_modules/**/*.ts", "!tests/**/*.ts"].

Member

ahejlsberg commented May 13, 2015

Right, the issue is that tsc.exe and the VS language service aren't in a position to take a dependency on node.js and therefore we can't use the node.js glob package. My feeling is that our best option so far is what is suggested in #3043: An exclude property in tsconfig.json that specifies a list of files and folders to exclude when a files list isn't explicitly specified. The net effect is the same as globbing with the list ["**/*.ts"] followed by a bunch of excludes. For example

{
    exclude: ["node_modules", "tests"]
}

would be equivalent to the globbing pattern ["**/*.ts", "!node_modules/**/*.ts", "!tests/**/*.ts"].

@poelstra

This comment has been minimized.

Show comment
Hide comment
@poelstra

poelstra May 13, 2015

Is there a standard file-globbing specification anywhere?

@CyrusNajmabadi There's the well-known .gitignore, although that of course is the 'inverse' of e.g. Atom Typescript's filesGlob.

@danquirk That package seems to have problems completely excluding a directory (see e.g. TypeStrong/atom-typescript#332), which is a must for excluding large node_modules folders. Additionally, it has had some breaking changes in the way it interprets its globs, and is apparently going to remove the negate-option.

Is there a standard file-globbing specification anywhere?

@CyrusNajmabadi There's the well-known .gitignore, although that of course is the 'inverse' of e.g. Atom Typescript's filesGlob.

@danquirk That package seems to have problems completely excluding a directory (see e.g. TypeStrong/atom-typescript#332), which is a must for excluding large node_modules folders. Additionally, it has had some breaking changes in the way it interprets its globs, and is apparently going to remove the negate-option.

@CyrusNajmabadi

This comment has been minimized.

Show comment
Hide comment
@CyrusNajmabadi

CyrusNajmabadi May 13, 2015

Contributor

Dan mentioned another possibility would be for us to just include glob.js in our compiler (if it was appropriately licensed). Then we would at least have the same syntax/behavior as an extremely popular package in the node space.

Contributor

CyrusNajmabadi commented May 13, 2015

Dan mentioned another possibility would be for us to just include glob.js in our compiler (if it was appropriately licensed). Then we would at least have the same syntax/behavior as an extremely popular package in the node space.

@poelstra

This comment has been minimized.

Show comment
Hide comment
@poelstra

poelstra May 13, 2015

@ahejlsberg Note that a pattern like "!node_modules/**/*.ts" would indeed lead to the same end-result, but will likely still traverse the full node_modules tree (because of the explicit *.ts at the end). Better would be e.g. just "!node_modules/" (or "!node_modules/**", if it detects that as a prefix-pattern).

@ahejlsberg Note that a pattern like "!node_modules/**/*.ts" would indeed lead to the same end-result, but will likely still traverse the full node_modules tree (because of the explicit *.ts at the end). Better would be e.g. just "!node_modules/" (or "!node_modules/**", if it detects that as a prefix-pattern).

@ahejlsberg

This comment has been minimized.

Show comment
Hide comment
@ahejlsberg

ahejlsberg May 16, 2015

Member

Just put up #3188 that adds support for "exclude" in tsconfig.json.

Member

ahejlsberg commented May 16, 2015

Just put up #3188 that adds support for "exclude" in tsconfig.json.

@ejsmith

This comment has been minimized.

Show comment
Hide comment
@ejsmith

ejsmith Jun 7, 2015

Exclude is not enough. Almost all other modern dev tools are supporting globbing. How can I say that I want all files from 2 folders and not include anything else without having to list individual files?

ejsmith commented Jun 7, 2015

Exclude is not enough. Almost all other modern dev tools are supporting globbing. How can I say that I want all files from 2 folders and not include anything else without having to list individual files?

@inongogo

This comment has been minimized.

Show comment
Hide comment
@inongogo

inongogo Jun 9, 2015

I think there is another use case which will not be fulfilled with an exclude option: ["**/*.ts", "!**/*.spec.ts"]

inongogo commented Jun 9, 2015

I think there is another use case which will not be fulfilled with an exclude option: ["**/*.ts", "!**/*.spec.ts"]

@ejsmith

This comment has been minimized.

Show comment
Hide comment
@ejsmith

ejsmith Jun 9, 2015

Yes, there are many scenarios that aren't covered by a simple exclusion.

ejsmith commented Jun 9, 2015

Yes, there are many scenarios that aren't covered by a simple exclusion.

ivogabe referenced this issue in ivogabe/gulp-typescript Jun 30, 2015

@kpko

This comment has been minimized.

Show comment
Hide comment
@kpko

kpko Aug 18, 2015

Hi,

is this still a thing? We have a huge typescript project and want to convert from the Visual Studio integrated typescript compilation to tsconfig.json files. We organized our files (mostly components) into many subfolders and it would be great if we could import them into the compilation without having to write hundreds of lines of "files" array items.

kpko commented Aug 18, 2015

Hi,

is this still a thing? We have a huge typescript project and want to convert from the Visual Studio integrated typescript compilation to tsconfig.json files. We organized our files (mostly components) into many subfolders and it would be great if we could import them into the compilation without having to write hundreds of lines of "files" array items.

@panuhorsmalahti

This comment has been minimized.

Show comment
Hide comment
@panuhorsmalahti

panuhorsmalahti Aug 18, 2015

Tip: you can use the "unofficial" glob property with e.g. atom-typescript and it works fine (the plugin will autocomplete all the files from the globs). It would be nice to get this into core, of course.

Tip: you can use the "unofficial" glob property with e.g. atom-typescript and it works fine (the plugin will autocomplete all the files from the globs). It would be nice to get this into core, of course.

@ToddThomson

This comment has been minimized.

Show comment
Hide comment
@ToddThomson

ToddThomson Feb 6, 2016

Contributor

TsProject supports file globs; minifies Typescript source; generates library and components packages and produces a single d.ts def file. file globs can be converted back to regular use for adherence to the standard.
TsProject is a NPM node package. I built it for my internal needs, but have and will add features that consumers need.

Contributor

ToddThomson commented Feb 6, 2016

TsProject supports file globs; minifies Typescript source; generates library and components packages and produces a single d.ts def file. file globs can be converted back to regular use for adherence to the standard.
TsProject is a NPM node package. I built it for my internal needs, but have and will add features that consumers need.

@bfricka

This comment has been minimized.

Show comment
Hide comment
@bfricka

bfricka Feb 20, 2016

I'm new to TypeScript, and from my naive, outside perspective, this issue looks hilariously bad for two key reasons:

  1. The tools are built around tsconfig.json. As far as I can tell, it doesn't matter if you're using VS Code, Sublime, WebStorm, etc. Thus, as one of the greatest selling points of a strongly typed language is how powerfully the static analysis and refactoring tools can interact with your code and provide useful features, buying in to an alternative build strategy isn't going to solve this issue.

    Sure I can glob and build in any language, but there are no hooks to then provide the results of this independent file resolution strategy to the tools. So if I want to use globs, what I get from TypeScript is static analysis (built-time) and an ES6 compiler with decent feature support. From this perspective, I'm better much better off with flow and babel.

  2. This is being held up by tsc.exe? Really?

bfricka commented Feb 20, 2016

I'm new to TypeScript, and from my naive, outside perspective, this issue looks hilariously bad for two key reasons:

  1. The tools are built around tsconfig.json. As far as I can tell, it doesn't matter if you're using VS Code, Sublime, WebStorm, etc. Thus, as one of the greatest selling points of a strongly typed language is how powerfully the static analysis and refactoring tools can interact with your code and provide useful features, buying in to an alternative build strategy isn't going to solve this issue.

    Sure I can glob and build in any language, but there are no hooks to then provide the results of this independent file resolution strategy to the tools. So if I want to use globs, what I get from TypeScript is static analysis (built-time) and an ES6 compiler with decent feature support. From this perspective, I'm better much better off with flow and babel.

  2. This is being held up by tsc.exe? Really?

@ananthakumaran ananthakumaran referenced this issue in ananthakumaran/tide Mar 4, 2016

Closed

Use filesGlob if available #16

@aliatsis

This comment has been minimized.

Show comment
Hide comment

aliatsis commented Mar 5, 2016

+1

@angelozerr angelozerr referenced this issue in angelozerr/typescript.java Mar 5, 2016

Closed

TypeScript nature #12

@MrJH

This comment has been minimized.

Show comment
Hide comment

MrJH commented Mar 7, 2016

+1

@myusrn

This comment has been minimized.

Show comment
Hide comment
@myusrn

myusrn Mar 8, 2016

does what is being proposed here allow me to have a projectroot/app/tsconfig.json and projectroot/scripts/tsconfig.json and in them, as well as projectroot/gulpfile.js tsc settings, specify an include of type definition files in their parent folders node_modules path, e.g. include ../node_modules/*/.d.ts ?

myusrn commented Mar 8, 2016

does what is being proposed here allow me to have a projectroot/app/tsconfig.json and projectroot/scripts/tsconfig.json and in them, as well as projectroot/gulpfile.js tsc settings, specify an include of type definition files in their parent folders node_modules path, e.g. include ../node_modules/*/.d.ts ?

@staff0rd staff0rd referenced this issue in MarkoSulamagi/Screeps-typescript-skeleton Mar 9, 2016

Closed

tsconfig.json - "files" and "exclude" are mutually exclusive #8

@nenadvicentic

This comment has been minimized.

Show comment
Hide comment
@nenadvicentic

nenadvicentic Mar 19, 2016

+1

For me, this would do the trick:

{
  ...
  "files": [
    "bower_components/**/dist/*.d.ts",
    "app"
  ],
  "exclude": [
    "node_modules"
  ]
}

+1

For me, this would do the trick:

{
  ...
  "files": [
    "bower_components/**/dist/*.d.ts",
    "app"
  ],
  "exclude": [
    "node_modules"
  ]
}

@kitsonk kitsonk referenced this issue in dojo/dojo2-package-template Mar 21, 2016

Closed

We should leverage `exclude` property in tsconfig.json #26

robertknight added a commit to hypothesis/h that referenced this issue Mar 23, 2016

Add Visual Studio Code project config file for JS
In combination with JSDoc annotations, this enables IntelliSense,
project navigation, inline documentation, refactoring and other goodies
using Visual Studio Code and other IDEs that integrate with TypeScript's
Language Service for JavaScript (aka.  'Salsa').

See https://code.visualstudio.com/docs/languages/javascript

The project file can be named either `jsconfig.json` without 'allowJs'
or `tsconfig.json` with the 'allowJs' config option enabled. I've opted
for `tsconfig.json` because that turns up better documentation on the
web and is recognized by more tools.

The project config file lives in h/static/scripts so that Visual Studio
only tries to parse and process .js files under that directory.  The
config file does support specifying the set of files to include, but
each file currently has to be listed individually. Glob support is
planned for the future. See
Microsoft/TypeScript#1927
@joshheyse

This comment has been minimized.

Show comment
Hide comment
@joshheyse

joshheyse Mar 23, 2016

I'm not sure excludes: [] option is going to able to handle enough scenarios, especially if it is mutually exclusive of files: [].

A lot of our projects have the following structure

├── node_modules
├── src
│   ├── client
│   │   ├── tsconfig.json
│   ├── common
│   ├── server
│   │   ├── tsconfig.json
├── node_modules
├── typings
├── gulpfile.js
├── package.json
├── tsd.json

There are 2 tsconfig files, 1 for the browser and one for node, each with different compile settings and file subsets.

Client tsconfig files: ['**/*.{ts,tsx,js,jsx}', '../common/**/*{ts,tsx,js,jsx}', '../../typings/browser.d.ts'].
Server tsconfig files: ['**/*.{ts,js}', '../common/**/*{ts,js}', '../../typings/main.d.ts'].

The tsconfig in the client directory should include all nested script files, plus the files in common and the browser typings.

The tsconfig in the server directory should include all nested script files, plus the files in common and the main (node) typings.

I haven't been able to come up with a combination of exclude or files (NON GLOB) that won't force me to be continuously managing the files array manually.

Currently we are maintaining the list of file manually. We tried to use atom-typescript to rewire the tsconfig, but it has problems with multiple tsconfig files in a single atom project.

I don't understand why file globing rules can't be used, they can satisfy all the requirements using a standard simplistic rule set.

I'm not sure excludes: [] option is going to able to handle enough scenarios, especially if it is mutually exclusive of files: [].

A lot of our projects have the following structure

├── node_modules
├── src
│   ├── client
│   │   ├── tsconfig.json
│   ├── common
│   ├── server
│   │   ├── tsconfig.json
├── node_modules
├── typings
├── gulpfile.js
├── package.json
├── tsd.json

There are 2 tsconfig files, 1 for the browser and one for node, each with different compile settings and file subsets.

Client tsconfig files: ['**/*.{ts,tsx,js,jsx}', '../common/**/*{ts,tsx,js,jsx}', '../../typings/browser.d.ts'].
Server tsconfig files: ['**/*.{ts,js}', '../common/**/*{ts,js}', '../../typings/main.d.ts'].

The tsconfig in the client directory should include all nested script files, plus the files in common and the browser typings.

The tsconfig in the server directory should include all nested script files, plus the files in common and the main (node) typings.

I haven't been able to come up with a combination of exclude or files (NON GLOB) that won't force me to be continuously managing the files array manually.

Currently we are maintaining the list of file manually. We tried to use atom-typescript to rewire the tsconfig, but it has problems with multiple tsconfig files in a single atom project.

I don't understand why file globing rules can't be used, they can satisfy all the requirements using a standard simplistic rule set.

@glen-84

This comment has been minimized.

Show comment
Hide comment
@glen-84

glen-84 Mar 27, 2016

@myusrn - Good question. I'll need the same thing. I would be quite surprised if this was not supported.

@nenadvicentic - You would use the include key in future, and the exclude in your case would not be needed.

@joshheyse - You can also use exclude to exclude everything except the files that you need. So for the client you would have something like:

"exclude": [
    "gulpfile.js",
    "node_modules",
    "src/server",
    "typings/main",
    "typings/main.d.ts"
]

A bit less to maintain, but still not ideal.

I don't understand why file globing rules can't be used ...

See my comment above.

glen-84 commented Mar 27, 2016

@myusrn - Good question. I'll need the same thing. I would be quite surprised if this was not supported.

@nenadvicentic - You would use the include key in future, and the exclude in your case would not be needed.

@joshheyse - You can also use exclude to exclude everything except the files that you need. So for the client you would have something like:

"exclude": [
    "gulpfile.js",
    "node_modules",
    "src/server",
    "typings/main",
    "typings/main.d.ts"
]

A bit less to maintain, but still not ideal.

I don't understand why file globing rules can't be used ...

See my comment above.

@jagt

This comment has been minimized.

Show comment
Hide comment
@jagt

jagt Apr 3, 2016

I've just started looking into typescript and the most frustrating thing is to get the 'namespaces' to work. Turns out I'll have to list all my files in tsconfig and the namespace resolution order will be correct. If I don't have the tsconfig (I'm using VS2015) or I omit the files section, the namespace will just break and I'll end up with an very stupid error on runtime, caused by the files are concated in random order.

I really like how VS intergrates TypeScript and how the intellisense works almost like wring C#, but the whole thing around namespace and files glob is so irritating and I don't know why there's nobody doing anything with this.

jagt commented Apr 3, 2016

I've just started looking into typescript and the most frustrating thing is to get the 'namespaces' to work. Turns out I'll have to list all my files in tsconfig and the namespace resolution order will be correct. If I don't have the tsconfig (I'm using VS2015) or I omit the files section, the namespace will just break and I'll end up with an very stupid error on runtime, caused by the files are concated in random order.

I really like how VS intergrates TypeScript and how the intellisense works almost like wring C#, but the whole thing around namespace and files glob is so irritating and I don't know why there's nobody doing anything with this.

@myusrn

This comment has been minimized.

Show comment
Hide comment
@myusrn

myusrn Apr 3, 2016

@jagt i'm thinking that explicitly listing the files you want to compile in tsconfig.json is not the norm and that more often then not one relies on tsconfig.json processing to process all *.ts files found in that path and below it except for excluded entries.

As for namespace resolution I've never run into any issues around ordering. I'm wondering if perhaps the matter here is not having a module loader in place, e.g. systemjs universal module loader, which as i understand it takes cares of loading import referenced namepaces. Once typescript enables use of es6 oob module loader support in, in target: "es5" output, then i'd guess one shouldn't have to enable any module loader in order to get import referenced namespaces loaded in relevant order.

myusrn commented Apr 3, 2016

@jagt i'm thinking that explicitly listing the files you want to compile in tsconfig.json is not the norm and that more often then not one relies on tsconfig.json processing to process all *.ts files found in that path and below it except for excluded entries.

As for namespace resolution I've never run into any issues around ordering. I'm wondering if perhaps the matter here is not having a module loader in place, e.g. systemjs universal module loader, which as i understand it takes cares of loading import referenced namepaces. Once typescript enables use of es6 oob module loader support in, in target: "es5" output, then i'd guess one shouldn't have to enable any module loader in order to get import referenced namespaces loaded in relevant order.

@jagt

This comment has been minimized.

Show comment
Hide comment
@jagt

jagt Apr 5, 2016

@myusrn I'm sorry about my wording of my last post. It really gets me after searching here and there trying to resolve this weird issue. I'd give you a detailed walk-through of what I've encountered.

As I stated before I've just started looking into TypeScript and started a VS2015 TS project. The first thing I tried to do, after going through syntax and stuff, is to separate code into multiple files. I tried using Modules first, and noticed that it needs an third party module loader like require.js. I'm not that into front end and don't have interest into loader things, and I found out there's this thing called Namespace, which seems to fit my needs exactly, as all I want to do is simply separate my source into multiple files. I do what the doc says, separate my test Class into an other file, and import it from my entry file. It compiles fine but fails in the browser. I checked the compiled output and figured it put the generated class after the first import statement, which is obviously wrong.

After a while I figured I have two solutions, one is to add <reference> comments, which I suppose is deprecated, and the other one to make it work is to manually list all my files in the tsconfig.json. If I do any of this the project will just work, and I'm sticking to the later one.

To make a long story short, I'm trying to find something like browserify in TS and figured that I can do that with namespace and listing files in tsconfig.json, which is kind of confusing.

Again thanks for your kind reply. I really like TypeScript and its VS integration, and despite of this issue (I had worse experience with other technologies 😉 ) most things goes where.

jagt commented Apr 5, 2016

@myusrn I'm sorry about my wording of my last post. It really gets me after searching here and there trying to resolve this weird issue. I'd give you a detailed walk-through of what I've encountered.

As I stated before I've just started looking into TypeScript and started a VS2015 TS project. The first thing I tried to do, after going through syntax and stuff, is to separate code into multiple files. I tried using Modules first, and noticed that it needs an third party module loader like require.js. I'm not that into front end and don't have interest into loader things, and I found out there's this thing called Namespace, which seems to fit my needs exactly, as all I want to do is simply separate my source into multiple files. I do what the doc says, separate my test Class into an other file, and import it from my entry file. It compiles fine but fails in the browser. I checked the compiled output and figured it put the generated class after the first import statement, which is obviously wrong.

After a while I figured I have two solutions, one is to add <reference> comments, which I suppose is deprecated, and the other one to make it work is to manually list all my files in the tsconfig.json. If I do any of this the project will just work, and I'm sticking to the later one.

To make a long story short, I'm trying to find something like browserify in TS and figured that I can do that with namespace and listing files in tsconfig.json, which is kind of confusing.

Again thanks for your kind reply. I really like TypeScript and its VS integration, and despite of this issue (I had worse experience with other technologies 😉 ) most things goes where.

@myusrn

This comment has been minimized.

Show comment
Hide comment
@myusrn

myusrn Apr 5, 2016

@jagt i haven't heard anything about use of /// <reference path="<path to .d.ts>" being deprecated and in fact you can see that's what i ended up using in https://github.com/myusrn/acxwithng2 and https://github.com/myusrn/dnxwithng2 main.ts files to allow me to use tsconfig.json with just excludes and still retain support for d.ts sources that exist in some of the excluded folders.

myusrn commented Apr 5, 2016

@jagt i haven't heard anything about use of /// <reference path="<path to .d.ts>" being deprecated and in fact you can see that's what i ended up using in https://github.com/myusrn/acxwithng2 and https://github.com/myusrn/dnxwithng2 main.ts files to allow me to use tsconfig.json with just excludes and still retain support for d.ts sources that exist in some of the excluded folders.

@brianrt

This comment has been minimized.

Show comment
Hide comment

brianrt commented Apr 8, 2016

@myusrn +1

@jvandemo jvandemo referenced this issue in jvandemo/generator-angular2-library Apr 14, 2016

Closed

Package typings file cannot contain tripleslash references #9

@lifenautjoe

This comment has been minimized.

Show comment
Hide comment
@lifenautjoe

lifenautjoe Apr 25, 2016

+1, its already a year later 😞

+1, its already a year later 😞

@trickpattyFH20

This comment has been minimized.

Show comment
Hide comment
@glen-84

This comment has been minimized.

Show comment
Hide comment
@glen-84

glen-84 May 11, 2016

@trickpattyFH20 Please use reactions now, instead of +1 comments.

glen-84 commented May 11, 2016

@trickpattyFH20 Please use reactions now, instead of +1 comments.

@dmagoo

This comment has been minimized.

Show comment
Hide comment
@dmagoo

dmagoo May 16, 2016

This would also be useful for avoiding ENOENT errors when using an editor that writes and removes backup files fairly often. I find it tripping over /.#file.ts which is often used by emacs.

dmagoo commented May 16, 2016

This would also be useful for avoiding ENOENT errors when using an editor that writes and removes backup files fairly often. I find it tripping over /.#file.ts which is often used by emacs.

@alexandrudima

This comment has been minimized.

Show comment
Hide comment
@alexandrudima

alexandrudima Jun 1, 2016

Member

For anyone interested in a workaround until filesGlob is added to tsconfig.json:

I've published typescript-with-globs that you can install side-by-side with typescript and you can begin using filesGlob in tsconfig.json.

After installing, you can use tscg (note the extra g) and it will first resolve the globs from filesGlob to the files section and then proceed to invoke tsc.

Member

alexandrudima commented Jun 1, 2016

For anyone interested in a workaround until filesGlob is added to tsconfig.json:

I've published typescript-with-globs that you can install side-by-side with typescript and you can begin using filesGlob in tsconfig.json.

After installing, you can use tscg (note the extra g) and it will first resolve the globs from filesGlob to the files section and then proceed to invoke tsc.

@mchambaud

This comment has been minimized.

Show comment
Hide comment
@glen-84

This comment has been minimized.

Show comment
Hide comment
@glen-84

glen-84 Jun 16, 2016

Shouldn't this be added to the TypeScript 2.0 milestone (along with the PRs)?

glen-84 commented Jun 16, 2016

Shouldn't this be added to the TypeScript 2.0 milestone (along with the PRs)?

@mhegazy mhegazy added the Fixed label Jun 22, 2016

@mhegazy mhegazy added this to the TypeScript 2.0 milestone Jun 22, 2016

@mhegazy

This comment has been minimized.

Show comment
Hide comment
@mhegazy

mhegazy Jun 22, 2016

Contributor

should be addressed by #8841.

Contributor

mhegazy commented Jun 22, 2016

should be addressed by #8841.

@mhegazy mhegazy closed this Jun 22, 2016

@vvakame vvakame referenced this issue in vvakame/typescript-formatter Jul 9, 2016

Closed

tsfmt does not recognize exclude in tsconfig.json #48

@christocracy christocracy referenced this issue in dapriett/nativescript-google-maps-sdk Aug 16, 2016

Merged

Implement `coordinateLongPress` event #61

@IAMtheIAM

This comment has been minimized.

Show comment
Hide comment
@IAMtheIAM

IAMtheIAM Sep 15, 2017

Great, in case anyone wonder, the property for including files as well as globs is "include", like this

    "include": [
        "./app/**/*.ts"
    ],

IAMtheIAM commented Sep 15, 2017

Great, in case anyone wonder, the property for including files as well as globs is "include", like this

    "include": [
        "./app/**/*.ts"
    ],

@Microsoft Microsoft locked and limited conversation to collaborators Jun 18, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.