-
Notifications
You must be signed in to change notification settings - Fork 135
tsd link exclusions #234
Comments
On the current TSD architecture, you're welcome to make a PR. However, on the version I'm currently building there isn't even a concept of |
what is your vision for replacing it? currently I'm using it to suck in ambient external module declarations I've created in a commons upstream project that all my projects depend on. |
There's an issue at #150, though I'm sure it's woefully out of date since I've now implemented most of it and hit lots of different roadblocks along the way, but basically every TypeScript module should define it's own dependencies in I'll have a minor release in the next few weeks (got stuck the last couple of weeks trying to rewrite dependencies inline, I think I'm going to revert that attempt lest this take another month). If you're interested, I can make sure I ping you when an alpha is available to leave feedback on. Do you have an example of how you're currently using this too? I would interested to make sure the use-case is covered in some way going forward, and perhaps have it as an example for the README for people to help transition. |
I just finished refactoring our projects to use this structure but I think its going to work out. Here it is. commons-project
downstream-project
Please let me know when an alpha is available. I'm the guy at work who tries to stay on top of the ever changing world of typescript node module stuff 😄 |
So |
correct. the commons project sucks in aws-sdk from tsd which has a Our previous solution to fixing this was to manually change the aws-sdk tsd gave us and commit the typings directory to version control. Then the downstream project would have reference comments in the js files to the aws-sdk-ext and life was terrible. this was also bad because it made staying up to date with the latest community type definitions too difficult. |
Ok, great. I might ask for a closer look later to understand properly, if that's ok (you can always email me directly, out of public space if you're worried). So in summary, I just need to think about how to cleanly define a module that mutates other modules? How does the dependency on |
I would second not the approach highlighted in the last comment (mutating existing definitions) but the original goal of being able to exclude definitions from the scope of To be specific, we have some internal modules that we want to depend on, and we'd like to use tsd as the glue to link typings automatically. However, Either a whitelist or a blacklist would suffice for this case (each with its own ups and downs, but I'm willing to eat the overhead either way in preference to the status quo). Really looking forward to a way to resolve this awkwardness without telling others to delete a specific set of lines from tsd.d.ts every build. |
@blakeembrey We don't re-export. The child project just includes references to This is our solution to quickly add to or adjust existing type definitions without requiring that every change we need is added to the DefinitelyTyped repo and do it in a way that can be shared with many of our projects that need it. |
I think it would be a good idea to allow for exclusions in tsd link. One of my dev dependencies is written in TS and exposes a typescript property in its package.json file (its a grunt plugin that wraps another module). I wouldn't expect to see this in my tsd.d.ts when I run tsd link but its there.
Good idea or no?
The text was updated successfully, but these errors were encountered: