Leokuma
can't access jsr packages in deno v1.3.6
You'll have to import (by using the
import
statement) either from here:
https://esm.sh/jsr/@std/io@0.224.8
Or from here:
https://cdn.jsdelivr.net/gh/denoland/std@release-2024.09.16/io/mod.ts4 replies
Deno Memory Usage Increases, Does Not Decrease.
How should we do this exactly? Should we run the program with
--inspect-wait
and keep the inspector connected all the time or is it possible to connect it to a running process at any moment?41 replies
Renders in dev mode (locally) but not on Deno Deploy
To deploy to Deno Deploy, we’ll make use of the GitHub integration. To use this the code needs to be pushed to a repository on GitHub. Once this has been done, one must go to the Deno Deploy dashboard and create a new project.
Click on the “New Project” button and select the GitHub repository that contains the Fresh project. Select the “Fresh” framework preset, and click on "Advanced options". Enter deno task build
in the “Build command” field. Press "Create project".
https://fresh.deno.dev/docs/getting-started/deploy-to-production10 replies
About imports
2. Where did you read that Deno does treeshaking? Anyway, even if it does, Deno favors explicit, clear code. When you read
import *...
, you can't tell what's being imported and used, whereas with import { delay } from...
, you know what's being imported and used. But you're still free to use *
if you like
3. Deno team recommends using JSR, avoiding URL imports and migrating from URL to JSR. But the community is still quite splitted regarding JSR. Many prefer URL imports. So it's up to you to compare the pros and cons and decide which way to go. It's a long discussion.
I believe there are packages that are only on deno.land
and not on JSR, but the Deno team is pushing everyone to migrate their packages to JSR. The latest versions of the Deno Standard Library are available only on JSR, although you can still import the latest version via jsdelivr
4. Where did you read that? $
was a common pattern to be used with import maps, but I'm not sure if it still holds true after JSR was introduced
5. Yes, but I think the advantage is generally not worth it.
For libraries, if you don't use an import map, it's easier to distribute your library because users don't need to care about the import map. An app can't load multiple import maps, so users of your library who already use an import map will have some trouble.
For applications, if you import the module directly in the source code, it's easier to read your code because you know where everything is coming from without looking at another file. Also, your code becomes "self contained" in the sense that each file has everything needed to run. It doesn't need anything else. It's a single-file application3 replies
Running multiple Deno versions at the same time
Hi, thanks for answering
My use case is I have a server (VPS) where I have something like a Deno cluster - or Deno "microservices" - and I'd like to upgrade the Deno version only for one service. I don't want to use Docker
7 replies
How to detect if executing on main thread vs worker
To type check a worker, add these lines at the top:
Source: https://docs.deno.com/runtime/manual/advanced/typescript/types#type-checking-web-workers
4 replies
How to rewrite this: `import * as base32 from "jsr:@std/encoding@0.224.3/base32.ts";`
Deno team is really pushing JSR, but personally I would not say JSR is "better" than HTTPS. I'd say it depends on your use case and the way you like to work. There are tradeoffs
5 replies
How to rewrite this: `import * as base32 from "jsr:@std/encoding@0.224.3/base32.ts";`
From https://jsr.io/@std/encoding@0.224.3/doc/base32/~:
Exports are declared in
deno.json
: https://jsr.io/@std/encoding/0.224.3/deno.json5 replies