DefinitelyTyped
Allow install from seperate repo like bower
In bower if there is a repo you want to include (like your own) that isn't listed in bower, you can install a repo by it's git url. It would be nice to have this feature with tsd so I can bundle d.ts files from repositories not included in DefinitelyTyped.
What kind of definitions would that be? Is there a reason why they'd not be in DefinitelyTyped?
For the current version I'd specifically made it to read only DT as we'd like to concentrate the community and it assumes a repos that is just a list of typings in folders. Your can use a different repos though, like a DT fork.
Also keep in mind it is advised to check-in defs into your VCS, as there is no clean versioning of defs like with npm/bower and their semvers.
That being said, multiple sources are on the radar for the next incarnation when I'm moving it to a more modular architecture.
My specific use case is that we are developing a TypeScript component that has it's own repo. This library isn't exactly perfect yet and ready for public consumption, and is being updated rapidly. What do you mean by "check-in your defs"?
Thanks for the case, it is something to keep in mind for us.
With checking-in I mean you put them in git/svn with your source code and commit them.
It is not 100% necessary as TSD can pull defs from DT by path+commit-hash, but in practice there is a big chance you'll edit the defs as they are user-created (imperfect) and also inevitably get outdated. If you have them in VCS you can make fixes and share them with your collaborators (and later push back to DT).
Ahh, I see what you mean. We don't commit code that isn't ours. We use package management for everything external to that specific project. (Cleaner repo's). If we need to modify something, we fork the original, make the changes, and pull request that.
Well, it'll work, but keep in mind definitions are a bit of an odd case and are not semantically versioned. There is no guarantee of backwards compatibility between updates.
But as long as you keep them by commit-hash and deliberately update when there is something new you'll be reasonable safe.
I personally like them checked in as not all my defs are in DT yet: many times I create new ones that I run for a while in my project before I push them to DT. In your case you could use a forked DT repository and set the "repo" field in tsd.json to your fork.
I was looking at this again while I was checking some possibilities for external (non-DT) files.
Would it be helpful if tsd.json would support an element that installs files by http(s) URL?
I was thinking about adding something like a remote element to the JSON:
"remote": {
"some-module" : [
"https://example.com/lib/main.d.ts",
"https://example.com/lib/addon.d.ts"
]
},
Then at some point TSD would grab these 2 files and put them in ./typings/some-module/main.dts and ./typings/some-module/addon.dts.
If that works out we could look into doing other transports besides http(s), like git+https etc.
+1
It would be nice to have the ability to pull down definitions from a fork hosted within the corporate firewall.
@scriby At this point TSD depends on the Github API but there is support for forks on Github (via repo field in tsd.json.
If you have connection problems then there is support for a proxy server (this was added at request of some corporate users). If you hit the github rate-limit because the whole office is using same IP then use the oath token. For both see the readme.
But I'll add a +1 to a way to be able to use any repo (eg: non-github).
My use case is a GitHub Enterprise (on-prem) instance, so just being able to point to a different GH instance (e.g. http://github.acme.com) would be nice.
Another case is "local package" (such as is being added for NPM v2.0), where the *.d.ts file is defined with another NPM module that is part of the same GH repo. NPM now allows packages to be defined with relative paths, so that multiple NPM packages can share a single GH repo. Similarly, TSD could allow a relative path (e.g. "../foo/foo.d.ts") instead of a commit, pulling the *.d.ts file from an adjacent NPM package subdirectory.
The ability to load from any git repo would be excellent. I believe that making this tool similar with the bower or npm (settings) has the effect of letting developers comfortable with this tool.
It also would help here: http://stackoverflow.com/questions/29857469/is-it-possible-to-reference-typescript-files-in-other-projects-without-adding-pr#comment47923706_29857469
@wedneyyuri Yes, this is part of the proposal in #150. I agree that it's a pretty important feature moving forward.
I would like this feature as well. I am using a .gitignore file that ignores the typings directory, and when I need definitions for external repos I have to place those in another directory :disappointed:
@Zorgatone Thanks, yeah, it's a common issue and one I run into myself also. The next version currently implements a radically different dependency scheme (though, there needs more thought into any potential issues) and it allows you to do something like:
"dependencies": {
"my-dependency": "github:DefinitelyTyped/tsd/path/to/definition.d.ts"
}
FWIW the word on the street is bower is dead ... long live npm.
Example : jquery installs
- on bower : http://bower.io/stats/ 198
- on npm : https://www.npmjs.com/package/jquery 38,000
Of course take this with a pinch of salt as all statistics :rose:
@basarat As right as you are about this, this issue is a comparison to Bower, not saying "from Bower" directly.
As for this feature now, there's not a TSD roadmap right now for providing this feature. I'm personally working on https://github.com/typings/typings which I intend to support installing ambient dependencies from DefinitelyTyped soon (https://github.com/typings/typings/issues/50 - right it already works manually (github:DefinitelyTyped/DefinitelyTyped/node/node.d.ts#commit for example), but this is an automated installation mechanism that'll resolve for you). The example I pasted above is the cruft of how typings works.