Use a custom compiler

[antoinerousseau]

It would be nice to be able to specify a custom TypeScript compiler binary, as seen here:
https://github.com/TypeStrong/grunt-ts#compiler

Because my project is not TS 1.6 ready, only TS 1.5

[sebastian-lenz]

TypeDoc does not support to specify a certain compiler version. If you have the need to stick to a particular version you should add the version of TypeDoc that suits your needs to your package.json.

[antoinerousseau]

ok ;-)

[sebastian-lenz]

Sorry for the quick copy and paste answer. The issue has been raised several times, you can find a longer explanation of why it is like that in #137.

[antoinerousseau]

ok thanks

[eggers]

There's a bug in 1.6.2 with returning non-promises from async functions (microsoft/TypeScript#5115) so I'm using typescript@next. It would be great if you added the option to specify the typescript version, if only as an unsupported option.

[DanielJoyce]

Yeah, we're on to 1.8 now.

[lisss]

For various reasons, we use 2.0 dev version of typescript so it still would be good to have an ability to provide custom compiler version.

[westy92]

I think this issue should be reopened. Sure, using old versions of typedoc to accommodate older versions of TypeScript works fine. However, this does not allow you to use newer versions of TypeScript. For example, I'd like to use typescript@next. Gulp-typescript handles this nicely: https://www.npmjs.com/package/gulp-typescript#typescript-version.

[gotschmarcel]

You should add typescript as peerDependency, so that users can use their installed versions of typescript.

[blakeembrey]

As nice and great as that is, the architecture is not set up for that at all. If you'd like to make a PR making those changes, I'd gladly accept it.

[gotschmarcel]

Why is that? Where's the difference between installing it as dependency via npm vs requiring it as peer dependency?

[blakeembrey]

One works with the project, one doesn't.

[j6s]

I would also be strongly in favour requiring typescript as a peer dependency instead of regularly.

There is literally no difference between the two - it should be as easy as changing it in the package.json

[blakeembrey]

Yes, there is. You literally can not use TypeDoc with 2.0 right now, it requires code changes to be compatible. If it were so simple, I would also change it - surprisingly I do understand how the dependencies work and do the same with every other project I maintain. But this project was not mine originally, I'm just trying to keep it floating. If you'd like to make changes happen, please help contribute.

[j6s]

Just to clarify:

Peer dependencies and using TypeScript 2 are separate issues. You can also require 1.8 as peer dependency if that is what this projects needs.

This is a good read, if you want to learn more about how peer dependencies work: https://nodejs.org/en/blog/npm/peer-dependencies/

[blakeembrey]

@j6s It might surprise you, but I know how peer dependencies work. If it moved to a peer dependency, then the next immediate issue would be someone installing 2.0 and logging issues that it's incompatible. What value is derived if it still has the same underlying issue? TypeDoc heavily depends on the TypeScript structure, if that changes then the peer immediately becomes invalid. Even from 1.4-1.8 the API surface changed significantly, TypeScript does not follow semver. For a peer dependency to be valuable, much of the code should be tidied up and refactored to support every version we say we does - not just the one single version which would act exactly like having a dependency but without any user safety anymore.

Edit: As I said, if you'd like to contribute, please do. If you don't, then that's also fine. But I won't just commit things on a whim if there's no positive upside for maintainers, contributors or users. You're welcome to share what you think is the upside here, but all you've said so far is "they are literally the same". When you say "literally" I assume you mean "figuratively" because they are most definitely not "literally the same thing".

[j6s]

just to double check: what's wrong with using this?

  "peerDependencies": {
    "typescript": "1.8.x"
  }

[blakeembrey]

It just doesn't provide any value (from my perspective). If you think this is wrong, please share. All it achieves is the same thing as a dependency, except maybe someone can install a slightly different patch version. On top of that, NPM v3 will allow an incompatible TypeScript version anyway, which will result in more support requests than there's bandwidth for. If you'd like to help out, please contribute!

[taoqf]

Hi, @blakeembrey , is it possible to passed typescript into typedoc as an optional argument? like gulp-webpack did?

[blakeembrey]

@taoqf It's not possible for the reasons I stated above (and somewhere else in the past). This project relies on a fair bit of internal TypeScript functionality and TypeScript doesn't follow semver, which means any version could break. It also requires at the top level, so it'd be a massive refactor to get that far. Of course, I'd love to see a PR that makes it an option, that'd be a great start, but I wouldn't expect the option to work for any minor version change difference just because of how often the TypeScript internals change (though it's slowed down a lot nowadays).

[taoqf]

@blakeembrey , How about this taoqf@44ee4be, maybe we would publish a unstable version under tag next.

[Gerrit0]

This is the goal for v1.0, and is being tracked in #880