Closed poelstra closed 10 years ago
Wow, you are quick (just pushed this first version out yesterday :)
The module is a bit of a hack-job to solve acute problem, so I'm not quite sure what is wise. It might be flawed (it still has to proof itself).
This code came originally from a project that exported some methods that returned types from a external definition, so iirc I added this reference handling to solve that. But I agree this becomes messy when you start combining these bundles and they all stomp global space. Your issue hasn't come up because I re-factored that out (for other reasons).
I'll have to look into trying to either merge referred content into the mangled string-namespace (if that works, as node.d.ts had globals and many sub-modules). That would make it nicely self-contained.
Otherwise maybe leave them out but somehow refer them to be installed as shared type to main typings folder.
Maybe it can be linked via the experimental typescript
element in package.json and some added logic in what is now upcoming TSD 0.6's link-command, which can already scan package.json and update tsd.d.ts with paths, so it might as well pull some shared dependencies.
Alternately it might relate to tsd.json somehow. But it goes a bit far to pull all of that as much of what is in there could be internals (or just for test suite stuff that doesn't relate to the package).
Let's think about this. I'm a bit distracted atm and knee deep in some other project. The problem is real enough though.
Thanks for the quick response! I'll make some kind of option to exclude external modules and send you a PR later.
Very cool.
If it is active then maybe stash the omitted data in an collection we can later see if we can do something fancy with it.
PR #3 adds support for excluding external typings (enabled by default).
As you requested, it also outputs a list of 'dependencies' as comments at the top of the generated output file (and in the verbose output).
Hi Bart,
We just started creating our own 'definition merger', also string-based. Yours seems much more elaborate though, so thanks for this!
I tried it out on one of our modules, but I stumbled across the fact that 'external' typings (such as node.d.ts, but basically any module that's being required with a non-relative path) are being included in the generated output.
This is problematic if I want to use these typings in another module, which will highly likely also include e.g. node.d.ts in its typings file (managed by tsd).
I hacked something in your code to leave these typings out, and to not mangle the require("...") statements in these cases, and that seems to work, but I have the feeling that I'm missing something, or that you may have a better idea to handle this.
For your reference, here's basically what I did:
So this basically leaves every 'external module' import intact, but seeing that you explicitly put some code in there to mangle them, I must be missing a use-case.
What's your take on this?