RunKit with TypeDoc?


Has anybody managed to automatically include RunKit with TypeDoc?

We have managed to insert it inside the documentation with some hardcoding help, but whenever we Run, runkit errors because it cannot find our code.

How do we programatically inject our code to RunKit?

We are very new to RunKit so any help is appreciated. The project is also Open Source here Pull requests · qoretechnologies/qorus-toolkit · GitHub - if you check out the PR and run the documentation you can see the error yourself :slight_smile:

Thanks a lot to anyone willing to help!


Hi there, I don’t have any first hand experience here, but it looks like what you want is to use the preamble feature of our embeds. The preamble is a bit of code that is hidden from the user that can set everything up so you don’t see a bunch of setup for every embed.

Usually in docs pages people just do something like:

const QorusAuth = require("qorusauth");

and call it a day, but sometime other helper functions (asserts for example) can also be defined.

It looks like qorusauth is not on npm yet (or if it is, I couldn’t find it) but it’s probably worth noting that you’ll need to publish the package to npm if you want it to be available on RunKit.

- Randy

1 Like

Hi me1000,

Okay - need to publish to NPM first - that explains it all!

Thanks a lot



We have run into an issue where RunKit does not see our pull request tags on NPM

It can find the library under @qoretechnologies/qorus-toolkit

But it cannot find the library under the @qoretechnologies/qorus-toolkit@pull_request_0.1.11663229869 tag.

We need to upload different versions of the library with each pull request so that RunKit can install the library version specific for that pull request and deploy the documentation.

Unforunately, RunKit says the library does not exist.

How can we make sure this works?


Hi there!

RunKit doesn’t really do anything with the npm tags, but you can require it using the version number itself, instead of the tag:

Unfortunately that version of your package is using ESM imports internally and not CommonJS requires. We’re actively working on getting ESM modules supported in RunKit, but it’s been a a longer than expected process for us as import do not behave the same as require.

We know import has been a pain point for NodeJS users and we want to make sure we get it right in RunKit. Until then, it looks like you’ve already got a build step for your package, so the transpiler you’re already using should be able to convert it to require fairly easily.

Okay the version works but I assume only because it’s been hours since published, because it did not work for me (how long does that usually take?).

Are tags never going to work? Like package@latest and package@beta ?

Thanks a lot

In general it only takes a few minutes between when a package gets published to npm and when RunKit processes it. Sometimes it can take a little longer because there’s a hiccup on our end, or npm’s. We did have a few minutes of downtime last night but it was several hours before you published your package.

Here’s some data I pulled:

Version 0.1.11663229459:
08:14:55 // npm publish time
08:51:53 // Received change rec from npm
08:52:05.248 // Package was made available on RunKit 

Version 0.1.11663229639:
08:18:57 // npm publish time
08:51:53 // Received change rec from npm
08:52:05.202 // Package was made available on RunKit 

Version 0.1.11663229869:
08:23:41 // npm publish time
08:51:53 // Received change rec from npm
08:52:05.205 // Package was made available on RunKit 

The first number is the time npm recorded the package being published. The second is when RunKit received the event via the npm replication feed, and the last is when the package was done being processed and made available.

As you can see we received a bunch of change records all at once from npm at 08:51:53 (UTC), once we received those changes we processed the packages’ versions and in your case they were available on RunKit about 1 second later.

We saw a minor uptick in errors from npm in the 8:00 hour, but nothing really notable so it’s hard to say exactly what happen.

As for supporting tags: we would like to eventually support requiring/importing anything you can describe in a package lockfile.