Add tsconfig for harness and tsserverlibrary, remove external dtses #9628
Conversation
| /// <reference path="sourceMapRecorder.ts"/> | ||
| /// <reference path="runnerbase.ts"/> | ||
| /// <reference path="virtualFileSystem.ts" /> | ||
| /// <reference types="node" /> |
There was a problem hiding this comment.
do not think you need all these /// <reference tags any more now that you have the tsconfig.json.
There was a problem hiding this comment.
Strictly speaking you should not, since it's in the config file. Not for the compilation, anyway. However for the editor experience, if the editor starts from the unittests folder and walks back to the harness (via the /// ref in the unittest), it doesn't always see the tsconfig in the harness folder and associate the unittest with that project (so adding the references into the harness file which gets included in all unittests covers it, making the editor experience without it finding the right tsconfig acceptable).
Only did this because it happened to me when reopening the editor while working on this.
There was a problem hiding this comment.
maybe we should move the unit tests to the harness folder. I just got lazy when we moved the code to github and did not move them.
There was a problem hiding this comment.
I can do that. It would make the structure look more sane, too.
There was a problem hiding this comment.
yup. back then there were only two of them, and we were planning to remove them.. but now we have much more :)
|
👍 |
|
@mhegazy I've moved the unittests into the harness directory. 😄 |
Adds a tsconfig for the harness and removes the ancient
node.d.ts(and chai and mocha) we kept in our repo (instead, we now use the@types/node(and chai and mocha) package(s)). Also, thelinttask is a bit more gulpy now - it uses globs to find files to lint, rather than a static list.We've been planning on adding a config file for the harness and tsserverlibrary for awhile (since they were the last major targets without one). The external
dtses needed to be removed since once I started pulling files from the configs, as I was made aware that some tests included a secondnode.d.ts, separate from the one the server included (and having nearly the same file in two different places is probably a mistake) - so rather than just collapsing them into one file, I just updated our build to use thenodetypes from@types, and added in our other "external"typesdependencies while I was there. (Since this is an exercise in modernizing our build).I'd also like to update our
tsconfigfiles to useinclude, but that will have to wait untilgulp-typescriptsupports the option.