When trying to import in deno, a lot of missing dependency errors are thrown #2075
Labels
deno
Status: Up for grabs
Issues that are ready to be worked on by anyone
Type: Bug
Something isn't working as documented
Comments
|
Does the plain JS work in deno, or is it just the TypeScript giving trouble? |
|
Relevant NodeJS to deno mappings |
index.ts// index.ts
// deno run --reload index.ts
import { Octokit } from 'https://cdn.skypack.dev/octokit?dts';
console.log(Octokit)Errors// index.ts
// deno run --reload index.ts
import { Octokit } from 'https://cdn.skypack.dev/octokit';
console.log(Octokit)No Errorindex.js// index.js
// deno run --reload index.js
import { Octokit } from 'https://cdn.skypack.dev/octokit?dts';
console.log(Octokit)No Error// index.js
// deno run --reload index.js
import { Octokit } from 'https://cdn.skypack.dev/octokit';
console.log(Octokit)No Error |
|
Thank you for reporting the problem, I'm having a look into it. For the time being, you can use import { Octokit } from "https://cdn.skypack.dev/@octokit/core?dts";
const octokit = new Octokit();
const { data } = await octokit.request("GET /");
console.log(data); |
|
It seems like you can re-create the import { Octokit as OctokitCore } from "https://cdn.skypack.dev/@octokit/core?dts";
import { paginateRest } from "https://cdn.skypack.dev/@octokit/plugin-paginate-rest?dts";
import { restEndpointMethods } from "https://cdn.skypack.dev/@octokit/plugin-rest-endpoint-methods?dts";
import { retry } from "https://cdn.skypack.dev/@octokit/plugin-retry?dts";
import { throttling } from "https://cdn.skypack.dev/@octokit/plugin-throttling?dts";
export const Octokit = OctokitCore.plugin(
restEndpointMethods,
paginateRest,
retry,
throttling
).defaults({
userAgent: `my-app/1.2.3`,
throttle: {
onRateLimit,
onAbuseLimit,
},
});
// istanbul ignore next no need to test internals of the throttle plugin
function onRateLimit(retryAfter: number, options: any, octokit: any) {
octokit.log.warn(
`Request quota exhausted for request ${options.method} ${options.url}`
);
if (options.request.retryCount === 0) {
// only retries once
octokit.log.info(`Retrying after ${retryAfter} seconds!`);
return true;
}
}
// istanbul ignore next no need to test internals of the throttle plugin
function onAbuseLimit(retryAfter: number, options: any, octokit: any) {
octokit.log.warn(
`Abuse detected for request ${options.method} ${options.url}`
);
if (options.request.retryCount === 0) {
// only retries once
octokit.log.info(`Retrying after ${retryAfter} seconds!`);
return true;
}
}
const octokit = new Octokit({
auth: Deno.env.get("GITHUB_TOKEN"),
});
const { data: user } = await octokit.request("GET /user");
console.log(user);
I do get the Type Intellisense in VS Code with the official plugin now.
|
|
The errors about The proper solution would be to take advantage of ES Modules and conditional exports in I'm not sure ho to workaround this problem for the time being, I'm open to suggestions |
|
I talked to folks in the deno Discord help channel. I learned about https://esm.sh/, but it shows even more errors than Skypack. The current build step adds /// <reference types="node" />which causes more errors, but Skypack replaces that line with /* Stripped by CDN: <reference types="node" /> */so I guess that helps. I see two possible solutions, besides the big ES Module rewrite
|
|
I tested it with the import { Webhooks } from "https://cdn.skypack.dev/@octokit/[email protected]?dts";It will cause a worse developer experience for node users, but only for the |
|
That seems like a fair compromise |
|
Okay I created two follow up issue for I hope that after these get resolved, this line will no longer fail with Deno import { Octokit } from "https://cdn.skypack.dev/octokit?dts"; |
|
@zingi would you like to help out with the two issues I linked above? I have other priorities right now, but I can review PRs ;) |
|
I would like to help out, but currently I don't have much spare time. 😕 If this issue still exists somewhere in the future, of the coming weeks or months I probably can try to help, |
|
Buy hey, maybe @laughedelic could help a little 😁 |
|
Haha 😆 you got me! I really want to be able to use Octokit from Deno. Just today I had to switch to Node.js because of these issues and I suffered a lot from just setting up the project 😞 I'll try to take a look into this later this week, but I can't promise! |
😁The changes are pretty straight forward, I think. Here is the PR I did for Basically the same changes need to be applied to the other repos. Don't get discouraged because you think it will take a lot of time, I don't think it will. And if you get stuck let me know and I'll try to help out |
|
Ok, here we go:
It was easy 😄 I hope this fixes it. |
|
The latest versions resolved the problem with The skypack CDN will take a moment to update the |
|
Thanks! I just tried to run my Deno script with |
|
🎉 This issue has been resolved in version 1.0.3 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
All right this code worked now: import { App } from "https://cdn.skypack.dev/octokit?dts";
const app = new App({
appId: "",
privateKey: "",
});
app.log.warn("ok");However, when I run it with |
|
Interesting, I just copied the code above and get these errors:
|
|
Same here |
|
@gr2m I don't know if it's related, but I had a similar issue when I tried adding the throttling plugin to the octokit/core. If I run this script: import { Octokit } from "https://cdn.skypack.dev/@octokit/core";
import { throttling } from "https://cdn.skypack.dev/@octokit/plugin-throttling";
const MyOctokit = Octokit.plugin(throttling);
const octokit = new MyOctokit({
auth: Deno.env.get("GITHUB_TOKEN"),
throttle: {
onRateLimit: (retryAfter: any, options: any, octokit: any) => {
return true;
},
onAbuseLimit: (retryAfter: any, options: any, octokit: any) => {
octokit.log.warn(`Abuse detected for request ${options.method} ${options.url}`);
},
},
});
octokit.log.warn("foo");It prints A workaround for this hanging is to add |
Can it be, that it set ups some unintended webhooks by default and just waits? |
|
no, it doesn't do anything like that. You have to call The same does not happen when I run the code in Node, so I'm curious if you know of any tricks on how to debug it in Deno? |
|
@gr2m do you think this issue may be reopened? |
|
I'd rather not reopen the issue, the original errors were addressed. But here is a follow up issue: #2079. I'd very much appreciate help with further narrowing down the problem. It's likely caused by |
|
I published import { App } from "https://cdn.skypack.dev/[email protected]?dts";
const app = new App({
appId: "",
privateKey: "",
});
app.log.warn("ok"); |
|
I no longer see an error, but the process still hangs. Any idea how to debug it? Does Deno have a way to show a list of open sockets or whatever could keep a process from closing gracefully? |
Well I took a look and was using 5.0.1 version of |
I just checked it and having the same 2 errors 😞 |
|
ugh me to, when I run it with |
I still can't debug it @gr2m, but this may help https://deno.land/manual/contributing/architecture#resources |
I checked with both |
@gr2m please try this, it may take sometime while you find the right file but once you have it, you can edit it in VSCode. |
|
The problem I'm having now is that I don't get the error when I run |
|
nevermind, even with |
|
Okay I confirmed that the simple change from import { Octokit as OctokitCore } from "/-/@octokit/[email protected]/dist=es2020,mode=types/index.d.ts";
export declare const Octokit: typeof OctokitCore &
import("/-/@octokit/[email protected]/dist=es2020,mode=types/dist-types/types.d.ts").Constructor<
void & {
paginate: import("/-/@octokit/[email protected]/dist=es2020,mode=types/index.d.ts").PaginateInterface;
} & import("/-/@octokit/[email protected]/dist=es2020,mode=types/dist-types/types.d.ts").Api
>;
export declare type Octokit = InstanceType<typeof Octokit>;to using import { Octokit as OctokitCore } from "/-/@octokit/[email protected]/dist=es2020,mode=types/index.d.ts";
export declare type SomeType = import("/-/@octokit/[email protected]/dist=es2020,mode=types/dist-types/types.d.ts").Api;
export declare const Octokit: typeof OctokitCore &
import("/-/@octokit/[email protected]/dist=es2020,mode=types/dist-types/types.d.ts").Constructor<
void & {
paginate: import("/-/@octokit/[email protected]/dist=es2020,mode=types/index.d.ts").PaginateInterface;
} & SomeType
>;
export declare type Octokit = InstanceType<typeof Octokit>;resolves the first issue. Unfortunately this is generated code, we do not have control over it. Also ... any idea why this is a problem? |
|
Unfortunately I don't know @gr2m. However I tested the package with ts-node and works pretty good. That's why I said maybe is it a Deno Typescript bug? |
|
Hi! thanks for pinging me. I'm watching your progress, but can't really help, I'm totally new to all this and have no idea how any of it works. Could it be a Skypack bug? They generate this code, if I understand correctly. I tried using import { App } from "https://jspm.dev/[email protected]?dts";
const app = new App({
appId: "",
privateKey: "",
});
app.log.warn("ok");And got a different error: This can probably be resolved with some modifications ( |
I am exploring a migration to native ES modules, but that is a bigger project. Unfortunately we are currently using As an in-between step I'd be open to replace |
|
For those looking for a quick workaround to just get their code running, |
What about using Rollup for that? It supports ESM generation by default and CJS via plugin. |
|
|
If pika worked well, might be worth looking at https://github.com/snowpackjs/snowpack since it's the newer ESM bundler from the same folks. Skypack literally replaced the Pika cdn. |
|
I know snowpack, I worked with them for a while :) It's a different scope, we need a build setup for universal packages, not a frontend build tool. |
|
Any updates on this? Still running into these errors while using |
|
We started work on https://github.com/octokit/octokit-next.js which, among other things, is all Native ESM so we hope it will work with Deno and other modern JavaScript Runtime Environments without a problem. However, work on Octokit is on hold right now I'm afraid: #620 (comment) |
|
I also get the same issue here when using My workaround is to import it like this but I have no types available But good news, I see that there is now a SDK team 👀
|
From |
|
In the latest Deno version you can import pacakges from npm so this: |
|
Similar to @Adidi, I've found that the npm specifier appears to yield expected objects and types.[1] However, worth pointing out that npm specifiers are only partially "stabilized." Note that:
The npm specifiers roadmap issue is: denoland/deno#15960 I think it would be helpful to add this alternative import (with a big asterisk [1] In general, skypack is acting rather odd for me. The search functionality in the web ui isn't working. The last blog post was in 2021. It looks like the relevant packages are up to date. But it seems like something might be off if they are sunsetting or similar? |
|
Great to hear that things are working better with deno when using the npm specifiers! PRs to update documentation are always welcome |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
What happened?
I wanted to import
Octokitin deno as described here.but a lot of missing dependency errors were thrown:
Error Output
What am I doing wrong?
What did you expect to happen?
no missing dependency errors
Environment
The text was updated successfully, but these errors were encountered: