tsd link exclusions

[mikedon]

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?

[blakeembrey]

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 link, so good idea 👍

[mikedon]

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.

[blakeembrey]

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 tsd.json, which will allow a recursive dependency installation without conflicts. Using it to install upstream external module declarations will result in pain in the end, since once someone else also does that you'll have conflicting versions.

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.

[mikedon]

I just finished refactoring our projects to use this structure but I think its going to work out. Here it is.

commons-project

• publishes a ambient external module definition (specifically I'm adding to the aws-sdk definition because its pretty poor). they are located in dist/typedef
• specifies the declaration file in package.json like

"typescript": {
  "definitions": [
    "dist/typedef/aws-sdk-ext.d.ts",
  ]
}

downstream-project

• depends on commons-project and needs the aws-sdk extension definition
• does not commit the typings directory tsd generates
• uses grunt-tsd to run link (adding link command grunt-tsd#14) which adds the aws-sdk extension to tsd.d.ts automagically as part of a normal build

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 😄

[blakeembrey]

So aws-sdk-ext.d.ts does a declare itself? E.g. everything is wrapped in declare "aws-sdk" or it it declare "aws-sdk-ext"? And itself is extending the aws-sdk module too? In any case, I'll ping you with the alpha release and you can play around and see if it can work for you and we can iterate from there.

[mikedon]

correct. the commons project sucks in aws-sdk from tsd which has a declare module "aws-sdk" and then in my ext file i do declare module "aws-sdk" and extend the module definition with added methods, classes, interfaces.

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.

[blakeembrey]

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 aws-sdk-ext then happen? Do you re-export it from your module in some way or you literally want the ability for a module to define mutations?

[henryptung]

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 tsd link.

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, tsd link is currently too aggressive for that, so e.g. if we also depend on tsc as a dev dependency, builds will break because tsc publishes its own typings (under the assumption that people may want to compile against tsc itself as a library, I suppose). The root issue is that for us, node_modules generally contains build tools as well (npm install ABC --save-dev), which we want to run during builds, not compile against.

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.

[mikedon]

@blakeembrey We don't re-export. The child project just includes references to aws-sdk.d.ts and aws-sdk-ext.d.ts (through typings/tsd.d.ts of course). The nice part about tsd link is that by just depending on our commons project which contains aws-sdk-ext.d.ts we can easily get references to everything defined in aws-sdk-ext.d.ts.

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.