Make tsd.json go away and become a section of tsconfig.json

[johnpapa]

2 files to manage typescript seems silly. Might be worth merging these.

[johnpapa]

copied from #199

@blakeembrey commented 32 minutes ago
@johnpapa That's no way to do that right now, but it's the aim for the next version of TSD. For now, I tend to store custom d.ts files somewhere else in the project and use tsconfig.json to reference them and tsd.d.ts. Does that answer your question somewhat?

[johnpapa]

Curious what the roadmap is for this to happen?

[Diullei]

I'm focused on stabilizing the TSD for now. I confess, I have not started to look into this issue, but I will do it soon.

All your suggestions are most welcome! :)

[johnpapa]

We appreciate your work, thanks.

I think long term it would be nice to have tsd's json become part of tsconfig.json. We have so many files these days, that it would be easier to have all of TS in one place. It's not kiling me in any way, but I think a section in tsconfig.json named tsd could just house what is in tsd.json today. perhaps a v1 breaking change

// cc @jonathandturner

[felixfbecker]

I dont think thats a good idea. I write vanilla javascript, but use tsd to install definitions for frameworks I use so I get IntelliSense for them in Visual Studio Code. Since I don't write TypeScript, I don't have a tsconfig.json...

[blakeembrey]

@felixfbecker Thanks for the feedback! I've implemented the future version using tsconfig.json to see how it feels and works, and there were other issues I found other than this (but nothing hard to solve). Would having a tsconfig.json, in your case, cause other issues?

As a side note, the other issue I found is that tsconfig.json promotes putting it anywhere in the project, not just at the root, so to resolve recursively with dependencies on projects like these there would have to be a field in package.json and/or bower.json to point to the correct tsconfig.json location. Not a big deal, but any thoughts on this @johnpapa?

[felixfbecker]

I don't think it would cause any other problems beside being weird. I also have a jsconfig.json, which they describe as something like a tsconfig.json, but for vanilla javascript, so VS Code knows im using ES6 and CommonJS etc. Having a tsconfig + jsconfig makes it even weirder... I think tsd stuff should belong into tsd.json. If I decide one day I don't want to use tsd anymore, I know what to delete...

Another option would be to simply read the npm.json / bower.json and if available, installing the correct definition versions of the libraries installed (don't know if that's possible).

Besides that, I really love how tsd allows me to get IntelliSense for foreign libraries, it's really great. I just wish it would work more like the other package managers, with semver, uninstall command and so on.

[blakeembrey]

@felixfbecker Thanks for the quick response. It is definitely a little weird, but it's not uncommon in the node ecosystem for configuration to exist in package.json under the module name. However, it's an odd one since you aren't in the TypeScript ecosystem technically (to be honest, it's the first I'm learning of this too). I'll wait for some more people to weigh in before I go definitely one way or the other though.

As for automatically resolving from existing packages, definitely going to exist in the near future so keep an eye out 😄 It will be as frictionless as possible and loosely based on someone else's comments here (tsd install --implicit) to install the dependencies that already exist. As for parity with other package managers comment, definitely agree.

[slikts]

Please don't do this; a separate file is easier to work with, makes it clear that the config exists and what it's for, and is more in line with what other tools do.

2 files to manage typescript seems silly.

DefinitelyTyped and TypeScript are separate things so it's reasonable for them to have separate configs.

[blakeembrey]

@slikts What about it makes it easier to work with? Ideally, you shouldn't be working with tsd.json or the tsd section in tsconfig.json in the future. If you draw the parallel to package.json, I used it with a few different packages (e.g. pre-commit, standard) for configuration and I find it much nicer than maintaining three files with a few lines each. Even npm technically expands upon package.json with their fields (http://wiki.commonjs.org/wiki/Packages/1.1).

[slikts]

What about it makes it easier to work with?

Removing or adding a file is easier than editing JSON. A separate config file's purpose is clear in all contexts; for example, there's no question about what's being changed if tsd.json shows up in git log. It's also the normal, expected practice. package.json is not a good comparison because it's general package data, but tsconfig.json is tool-specific config that can also have multiple instances. There has been no case made here for a separate file being problematic except for just calling different tools having separate config files "silly" or saying that using tsconfig.json would be "nice". Instead, if you couple the configs, you get problems like not being able to validate them with a schema, or possibly overwriting the formatting, or conflicts with other tools that are writing to the file, like atom-typescript which already has this misfeature. It's just unclear why would you want to do this, especially because it'd be a breaking change.

[blakeembrey]

@slikts Thanks for your input, it's definitely all valid. In fact, your comment on atom-typescript about adding comments to tsconfig.json is a good reason to avoid tsconfig.json. As much as I would love to avoid a bunch of configuration files, it won't be stable to use a format that can change from underneath us.