Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 07:20
    DanielSWolf commented #1403
  • 06:29
    Shane4368 commented #1706
  • 03:22
    zhixinbao commented #940
  • 02:30

    Gerrit0 on master

    Update changelog (compare)

  • 02:26

    Gerrit0 on master

    Infer the name of a destructure… Add unit tests for functions wi… Merge pull request #1704 from G… (compare)

  • 02:26
    Gerrit0 closed #1704
  • 02:26
    Gerrit0 closed #1703
  • 02:23
    Gerrit0 commented #1704
  • 02:17
    Gerrit0 commented #1708
  • 02:12
    Gerrit0 labeled #1709
  • 02:12
    Gerrit0 labeled #1709
  • 02:12
    Gerrit0 opened #1709
  • 02:05
    Gerrit0 commented #1706
  • Sep 22 20:36
    pat-son labeled #1708
  • Sep 22 20:36
    pat-son opened #1708
  • Sep 22 18:04
    Shane4368 commented #1706
  • Sep 22 15:10
    srmagura commented #1556
  • Sep 22 15:09
    Shane4368 commented #1706
  • Sep 22 13:21
    Gerrit0 commented #1706
  • Sep 22 04:30
    issadarkthing opened #1707
Gerrit Birkeland
@Gerrit0
It will result in most plugins giving a deprecation warning when loaded. I believe they will still work, however. Pretty much every plugin I've seen grabs either the application or owner property on the passed object, which still points to the application.
The decision to make that change was made for a couple reasons:
  1. There was nothing actually useful to plugin devs on PluginHost
  1. PluginHost wasn't exported, so properly typing a plugin required importing an internal path
Krisztián Balla
@krisztianb
Oh, I didn't notice that Application has an application getter. :-)
Alireza
@sedghi
Hi, I'm not able to include my image inside the typedoc generated documentation, does anyone know what should i do?
I'm basically saying ![image](./image.png) but doesn't appear my image is accessible inside page
xiedongxiang
@XDXXDXXDXXDXXDX
hello
anyone here? i need help
i use typedoc v0.20+ it is quite different from v0.19, i cant ignore wrong to build doc
node_modules cant be exculde
Krisztián Balla
@krisztianb
@XDXXDXXDXXDXXDX I think you will need to show us how you are calling TypeDoc (and maybe your config) in order for us to be able to help you.
You might also want to look into the entryPoints option which is what makes the newer versions different.
@sedghi where do you want to include your image? In which file are you using that markdown?
AurisAudentis
@AurisAudentis
image.png
Hi! Quick question. I would like my modules to be organized in the menu by folder they are in, instead of all flat, so it's not too overwhelming. I'm not sure how to make that happen, could anyone help?
I use the following command to run typedoc, and i suspect it has something to do with that: typedoc --out docs src/**
Gerrit Birkeland
@Gerrit0
I believe there is a theme that does that, there isn't a builtin way to do it
Typedoc-neo-theme looks like what I was thinking of
AurisAudentis
@AurisAudentis
looks interesting, let me give that a shot!
Gerrit Birkeland
@Gerrit0
Alternatively; for most projects I don't think giving TypeDoc every file is the best solution. If you have index.ts files which re-export the contents of each folder, it might be better to give typedoc only those
AurisAudentis
@AurisAudentis
I don't, actually. We're using typedoc for a browser-based application at the moment, so I'm not sure re-exporting everything is useful/necessary, but if it is the proper form i'll do it
Gerrit Birkeland
@Gerrit0
Might not be a great fit for your use case then, typedoc has really focused on libraries in the last couple versions, which tend to export everything from a few entry points
AurisAudentis
@AurisAudentis
Yes, I noticed. It's still a massively useful piece of software, however
We're inclined to keep using it until it breaks entirely
Gerrit Birkeland
@Gerrit0
If you're happy with the current output, no need to change, I suggested it because it looks like some of those modules will only have a single exported class, so having a single entry point for everything under Renderers for example might be nice
AurisAudentis
@AurisAudentis
That would make a lot of sense I feel, I assume the classes that i re-export would still be documented?
Gerrit Birkeland
@Gerrit0
Yep, typedoc can follow re-exports
AurisAudentis
@AurisAudentis
I'm going to give that a shot, then; the neo theme you mentioned is sweet but can't handle the long module names
Thanks for your help!
Gerrit Birkeland
@Gerrit0
:+1:
AurisAudentis
@AurisAudentis
The tips you provided are a big help, it looks a lot better now. One more thing I'd like to ask though: is there any way to 'nest' these module pages? I presume there isn't, since you can't nest modules either, but it wouldn't hurt to ask
Gerrit Birkeland
@Gerrit0
It depends on what exactly you mean by nest... if you have a re-export like export * as Something from "./something" typedoc will create a namespace. There isn't a way to show files in folders though
Hrach
@hrachocode
guys anyone with experience of checking if every public module has been documented or no upon project build? and if public method documentation is missing, throw error, anyone I can realize this with typedoc?
Gerrit Birkeland
@Gerrit0
You could write a plugin to traverse all types and make sure any ReferenceTypes actually point to a reflection
aaronfg
@aaronfg
if my entry point is src do the exclude dirs mean dirs within that entry point? ie don't worry about node_modules because it's not in src/node_modules or is that not the case? I'm getting errors from typedoc trying to parse the node_modules folder.
{
    "entryPoints": [
        "./src"
    ],
    "out": "docs/typedoc/markdown",
    "exclude": [
        "**/*.js",
        "**/node_modules/**",
        "**/docs/**",
        "**/__mocks__/**",
        "**/__tests__/**"
    ],
    "excludeExternals": true,
    "excludePrivate": true,
    "disableSources": true
}
that's my config
Gerrit Birkeland
@Gerrit0
With the exeption of theme, paths are resolved relative to the file they appear in (cwd if provided on the command line)
If you compile with tsc, TypeDoc should report the same errors
Krisztián Balla
@krisztianb
@hrachocode that's an interesting topic. Documentation coverage is supported by Compodoc a tool I used a couple of years ago to document one of our projects. Might be something worth adding to TypeDoc.
tiran sameera wijesekara
@tiranuom
Hi All, It seems like the documentation comments in the export { a } from 'b' are not rendered in the doc. Is there any way I can add a documentation comment to a reexport?
Gerrit Birkeland
@Gerrit0
TypeDoc should pull the comments from the declaration of a in b... that might be a bug. You should also be able to add comments on the re-export and we should be able to pick that up too
Raynor Chen
@capraynor
Folks:
Are there any documentations about typedoc library mode?
Alright, found one: TypeStrong/typedoc#1184
Gerrit Birkeland
@Gerrit0
I'd recommend looking at the release notes for 0.20 as well
Krisztián Balla
@krisztianb

I'm having a problem with the options of one of my plugin.

This is how the option is defined:

/**
 * Extend typedoc's options with the plugin's option using declaration merging.
 */
declare module "typedoc" {
    // eslint-disable-next-line @typescript-eslint/consistent-type-definitions -- This is not a separate type.
    export interface TypeDocOptionMap {
        "replace-in-comments-config": ReplaceInfoFromConfig[];
    }
}

When accessing the value like this:

const config = typedoc.options.getValue("replace-in-comments-config");

config has the following type according to TSC:

const config: number | ReplaceInfoFromConfig | (() => IterableIterator<ReplaceInfoFromConfig>) | (() => {
    copyWithin: boolean;
    ... 5 more ...;
    values: boolean;
}) | ... 28 more ... | (() => string)

But it should be: ReplaceInfoFromConfig[]

Am I missing anything?

The array type is defined like this:
/**
 * A type describing what should be replaced by what as it is defined by the user in the config.
 */
type ReplaceInfoFromConfig = {
    /** The regular expression pattern used to find the text that should be replaced. */
    pattern: string;

    /** Flags for the regular expression pattern. */
    flags?: string;

    /** The text that should be used as a replacement. */
    replace: string;
};
Gerrit Birkeland
@Gerrit0
That definitely seems like a bug...
Oh, wait, maybe not... typedoc doesn't really support arrays which aren't strings as options so its probaby going into some branch that typedoc never sees...
I would still expect that to work, or maybe be unknown, not... whatever that is