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
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.
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.
RunKit doesn’t really do anything with the npm tags, but you can require it using the version number itself, instead of the tag: require("@qoretechnologies/qorus-toolkit@0.1.11663229869");
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.
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.
