-
Notifications
You must be signed in to change notification settings - Fork 12.9k
Description
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'
]
Activity
danquirk commentedon Feb 4, 2015
We certainly talked about this for awhile. See Anders' comment here for one large concern: #1692 (comment)
JeroMiya commentedon 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 commentedon 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 commentedon 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 commentedon 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.
basarat commentedon Feb 11, 2015
FWIW atom-typescript supports
filesGlob
as an optional extension tofiles
. See spec.NoelAbrahams commentedon Feb 11, 2015
@basarat,
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
basarat commentedon Feb 11, 2015
Just a note: whenever atom-typescript reads a file with
filesGlob
it expands thefiles
in 'tsconfig.json' file so that people that are not using atom-ts will still get the correct list of files.rcollette commentedon 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.
bidiboom commentedon 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 commentedon 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.
112 remaining items
glen-84 commentedon May 11, 2016
@trickpattyFH20 Please use reactions now, instead of +1 comments.
dmagoo commentedon 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.
alexdima commentedon Jun 1, 2016
For anyone interested in a workaround until
filesGlob
is added totsconfig.json
:I've published typescript-with-globs that you can install side-by-side with
typescript
and you can begin usingfilesGlob
intsconfig.json
.After installing, you can use
tscg
(note the extrag
) and it will first resolve the globs fromfilesGlob
to thefiles
section and then proceed to invoketsc
.mchambaud commentedon Jun 1, 2016
@alexandrudima 👍
glen-84 commentedon Jun 16, 2016
Shouldn't this be added to the
TypeScript 2.0
milestone (along with the PRs)?mhegazy commentedon Jun 22, 2016
should be addressed by #8841.
coordinateLongPress
event dapriett/nativescript-google-maps-sdk#61IAMtheIAM commentedon Sep 15, 2017
Great, in case anyone wonder, the property for including files as well as globs is "include", like this