Deno doesn't download anything that isn't imported, so "publishing" isn't like it is on npm where the whole packages is downloaded. The README will be on deno.land, but it wont get downloaded because it won't be imported.
deps.ts
file, and import from that file when using them within your project, then you have a single point to change for version control across the project.Here is the relevant part of the manual: https://deno.land/[email protected]/tools/compiler
You probably just need to run
deno compile --allow-net --target <TARGET> path/to/script.ts
for each platform (target) you want. That should create a binary that your students can just double click to run.
^ This
OP seems to look out for tools in a “Node.js manner”. Though this is not the point of Deno. Deno has batteries included in tries to get rid of these unnecessary arbitrary decisions you need to take with Node projects (linter, testing, bundler, etc.)
Just simply leverage the Deno standard library and guideline. I believe this opinionated view of Deno is its beauty.
I wrote these: https://deno.land/x?query=feoblog
feoblog_client is the client library, and the other 3 are tools that use it to grab data from RSS/Mastodon/Twitter.
The best practice is to put dependencies in a deps.ts file as explained here: https://deno.land/[email protected]/examples/manage_dependencies . The virus concern that you have is mitigated by using the security flags including --allow-write and --allow-read for file access and --allow-net for network access. These flags allow you to specify what files or network sites the program can use to minimize attack surfaces. Node does not have this mechanism, and history has taught us that npm can harbor rogue libraries.
If you’re writing something like a CLI (any discreet non-long running thing), you can use the Deno Permissions API to request and revoke permissions (https://deno.land/typedoc/classes/deno.permissions.html)
I’d hope module writers could wrap any method requiring permissions in a request/revoke sandwich so permissions don’t leak out into other code. This likely wouldn’t happen until the API becomes stable though, and requires module writers to put in the legwork (so no help to end users potentially if they haven’t). It would also only really be practical for CLI like tooling as requests require manual intervention (and to use expect scripts to auto-grant would just defeat the purpose!)
You’ve actually got me interested in it to be honest, if you do have a play with it let us know your findings :p I guess Deno is easier to setup compared to Node and Python, you run 3 commands to install and that’s literally it
I get what you mean, obviously Python and Node are the ‘safe’ options due to the maturity, but if you haven’t already have a look at Deno’s third party modules: https://deno.land/x/, see if there’s anything there that can help your decision
You can create a single file (usually called deps.ts) where you import all external dependencies. You can then import this deps.ts file in your source code. If you want to change one package version or change it's source, just do it from the deps.ts file.
//deps.ts export * as log from "https://deno.land/x/[email protected]/mod.ts";
//main.ts import {log} from "./deps.ts";
If you don't like using a single file to manage your dependencies, you can still use your IDE to find and replace the URL in all your source files.
Deno cache every package you try to import. It will download it from URL only if he can't find it locally. It's the same issue with other package managers.
I think the only improvement deno can make is to let us declare a "node_modules" equivalent in a local config file or something. It's sometimes useful to deploy a node application without running "npm install" and shipping it with a full "node_modules" folder.
Deno like Node is a backend server. Unless you are using React Server ( https://reactjs.org/docs/react-dom-server.html ), you are doing things wrong.
What you should do in order to create a frontend in typescript should be create a Create React App with typescript. https://create-react-app.dev/docs/adding-typescript/
Use Deno because it's like NodeJS but is much safer and faster (no node_modules, caches packages, etc.)
Npm also caches installs you just get a new copy in the project rather than a global cache, which you can get in node with the use of Pnpm
I assume by now you already know, but successfully installed it using the install command:
curl -fsSL https://deno.land/x/install/install.sh | sh
​
Deno was installed successfully to /home/pi/.deno/bin/deno
Manually add the directory to your $HOME/.bash_profile (or similar)
export DENO_INSTALL="/home/pi/.deno"
export PATH="$DENO_INSTALL/bin:$PATH"
Run '/home/pi/.deno/bin/deno --help' to get started
I’d like to merge a module I made with the std. I don’t think it fits in collections because it contains generators not functions that return arrays. What are your thoughts on this? https://deno.land/x/[email protected]
Hi :)
I tried running the TCP example using windows, and it's working as expected. The manual on the main branch provides better instructions for Windows: https://deno.land/manual@main/getting_started/first_steps#tcp-server. Let me know if you're still having issues.
Deno has recently revamped a lot of the HTTP/WebSocket stuff under the hood, so it wouldn't surprise if some random, not that actively maintained websocket library has become incompatible with current versions of deno.
May I suggest using the "official" ws library that is found in the deno std modules; that's maintained by the deno devs and should be up to date with latest developments: https://deno.land/std/ws/README.md
Given that ws.send is an async function and that your error is complaining about uncaught error in a promise, didn't you have to await ws.send()?
I use the sqlite module and wrote a function that returns the rows from the sql query as an array of { columnName: value }
objects
Hi there! I archived the repo since I don't have much time to improve on it and also in the end I ended up not liking the overall architecture (too much OOP style) because lately, I'm hopping over to the FP bandwagon (I may give it another go someday and build a new task scheduling library for deno 🤷♂️).
Anyway, the only library I know of is `deno_cron` but it does not have database sync support (for your tasks).
You can always use this archived lib (https://deno.land/x/[email protected]) but I definitely don't recommend it for prod applications.
Here is a project I know of which addresses the concern of embedding file assets into a "compiled" binary: https://deno.land/x/leaf
I haven't used it personally but it seems to have some userbase on the Deno Discord community.
Looking at what you can achieve today, if it’s enough to restrict permissions on immediate dependencies ( and group that with all sub deps of said dependency) you could make use of the Permission interface of Deno workers ( REF: https://deno.land/manual/runtime/workers#specifying-worker-permissions ) where you can perform your imports in said workers with restricted permissions compared to your first party application code. This has its own limitations, will incur a perf/resource hit etc and not provide the granularity and control you suggest, but is an option when it comes to sandboxing. By way of PoC check out https://github.com/asos-craigmorten/importw
I've been looking at how to bundle up Vue single-file components from a Deno script without relying on having a node_modules toolchain installed so this project is quite interesting.
I've already interacted with the issue tracker a little bit :) but is there a public roadmap for this project? For example, prioritization of some big picture items like:
defineComponent()
to build the exports).vue
files (vno as a library)<style lang="less">
or <script lang="ts">
(sass appears to have a Deno binding already, while typechecking TypeScript components sounds like it could be a real nightmare... maybe some pluggability/dynamic importing to be designed here)It seems like there's several people investing in this tool so it'll be cool to see where it goes!
use the manual, the debugging info is in the first section: https://deno.land/manual
existing source code will get you rolling--if you don't already know typescript just write javascript instead. It's almost exactly like writing js for any modern browser.
install deno (see deno.land) then deno run -A something.js
where somethingj
I understand that you're having frustrations. Deno is significantly newer than Node, and the number of resources is smaller, but there is documentation. I found an example server by doing the following:
Visited deno.land Checked out the standard library (I happened to already be aware of the http module here) Clicked on http.
The resultant documentation: https://deno.land/[email protected]/http
If you're looking to start a server, I would also check out the oak (modeled after koa) and opine (modeled after express) frameworks. They can be found in the third party modules sections.
I made mock for deno. It has spies, stubs, and a way to fake time for tests. I will update it for deno 1.6 today. It works with 1.5.x currently.
For tests that may require setup/teardown, I created test_suite. It's basically just a wrapper around Deno.test
that adds the ability to group tests and add setup/teardown hooks.
You should use bundles to achieve this, as it will compile your main module and it's dependencies into a single js file that can be imported into a browser
Manual | Deno
Hi cdoremus.
Sorry, you lost some time, as of today yes, most projects are not portable in practice.
But I hope we will get there eventually a module only has to be made compatible once and then it is done for everyone else.
The main brake as of today is the incompleteness of the node compatibility layer of Deno.
Once we'll get http
, net
and stream
things will snowball from here.
As for test frameworks, those are devs dependencies, the devs dependencies do not have to have a Deno equivalent for à project to run on Deno.
I think there are already some modules out there.
I created validator that is a value validator and also is extendable.
There is also segno which is super rich in functionality.
But to check if an object is an instance of a type, you can just use instanceof
:
value instanceof Promise
value instanceof RegExp
Since you can fetch modules wiht urls you don't need a manager for that anymore. Deno takes that workload (downloading, caching) for you.
To search modules: Deno has [3rd party modules](https://deno.land/x) where you can search modules that point to individual repositories.
I think this is really cool, because even that webpage is opensource. So potentionally anybody can setup a webpage that functions as a module .
Is any library ever stable?!
The Deno docs recommend using versioned library URLs such as: <https://deno.land/[email protected]/http>
Your code should never break unless you decide to update the version.
Sorry for what seems like my many 'complaints'. I just want to notify other users of some issues that they may run into.
My latest finding are:
- The React types have disappeared from https://deno.land/x/types, but posts on the Deno channel on Discord pointed me here: https://github.com/Soremwar/deno_types. I cloned that repo and copied the react-related typings into the types folder, replacing ones that were already there and referencing those files in the @deno-types
annotation.
- After doing the previous steps, I can get attain build
to work on my Ubuntu 10.04 machine (16 GB RAM) with Deno 1.2.2 and Attain 1.0.10, but running the server throws 22,800 errors all of them appear to be related to TypeScript typings and many look like they come from the material-ui library.
- I'm still getting the errors I reported previously on my Macbook Pro.
Clearly development with Deno bundling React with TypeScript is in its infancy, so if you want to get involved be prepared for a bumpy ride. This probably has as much to do with the state of Deno itself than any library. After all its initial use has been on the server side where there are far fewer problems.
Can you elaborate a little more? I’m assuming that you are trying to create some sort of web application because you mentioned html, in which case an http server is probably what you are trying to make. This is a much larger topic and not really Deno specific, but you can most certainly build an http server in Deno. The standard library would be an excellent starting point, and you should get familiar with it before starting to look at frameworks https://deno.land/std/http/server.ts
Then you need to decide on an architecture: is it a monolith? A static front end pulling from a REST API? A SPA pulling from a REST API? Are you going to use websockets? The rabbit hole goes as deep as you are willing to go!
I like the post. I wish the post also mentioned integrity checking though.
https://deno.land/manual/linking_to_external_code/integrity_checking
You can and should create a lock.json
file for your Deno module, so that when people pull your dependencies in the future, they can know that they have pulled the same files that you did.
The previous two comments cover it really, only gotchas to add is that:
—unstable
flag when running.read
permission will return false for something like deno run --allow-read=/etc
unless you also pass the path
argument of /etc
(or equivalent for other scoped permissions)REF: https://deno.land/typedoc/classes/deno.permissions.html#query
Since it ships with chromium, the app size will be large. One solution to this, if you are targeting a single platform, is to use Deno Webview, which will use a default rendering engine already installed on the computer, and thus the total size will only be around 20-30mb when compressed.
Deno Oak
// app.ts import { Application } from "https://deno.land/x/oak/mod.ts" import router from "./routes.ts"
const app = new Application()
app.use(router.routes()) app.use(router.allowedMethods())
console.log("App running on localhost:3000"); await app.listen({port: 3000})
​
// routes.ts import { Router } from "https://deno.land/x/oak/mod.ts"
const router = new Router()
router.get("/", ({response}: {response: any}) => { response.type = '.html' response.body = "hello noobs" })
export default router
deno run --allow-net app.ts
Please correct me if I’m wrong (and if so, probably needs updating in the docs!) but I believe the comma separated arguments you can pass to —allow-net
are actually allowed domains to be requested, not a list of filenames? Afaik you can’t scope permissions to a file in this way?
Deno also has lots of third-party modules one of which is abc you can use the same to create a simple web API check out this blog to set up a basic web app.
have a look at the std path module, it has some functions to deal with extracting the path from the URI (fromFileUrl
) and to extract relative paths (e.g. from cwd) (relative
). it will also deal with the different pathing between windows and posix for you.
Exactly! I’m guessing a good starter for 10 would be to have a small module that utilises the Deno Permissions API which will revoke any/all permissions not definitely required, or perhaps just prevent app start.
This would mean we could run security as code and be less likely to accidentally dump over-scoped flags onto the run command (and people do, be protected from it)
At least for me, a good reason to continue using JavaScript is this: https://deno.land/v1#tsc-bottleneck
> Internally Deno uses Microsoft's TypeScript compiler to check types and produce JavaScript. Compared to the time it takes V8 to parse JavaScript, it is very slow. Early on in the project we had hoped that "V8 Snapshots" would provide significant improvements here. Snapshots have certainly helped but it's still unsatisfyingly slow. We certainly think there are improvements that can be done here on top of the existing TypeScript compiler, but it's clear to us that ultimately the type checking needs to be implemented in Rust. This will be a massive undertaking and will not happen any time soon
Of course, using TypeScript is probably "fast enough" for most small apps or services, and I have no doubts that TypeScript performance will increase exponentially going forward, but it is something to consider.
Hi there! Yes DI is on the cards for sure - I really built this as a proof of concept to make sure reflect-metadata and function decorators behaved as I expected in Deno, which they do. https://deno.land/x/alosaur is a great project and sets out to achieve a lot of what NestJS does for Deno. I only became aware of alosaur after the fact but there are some things I would like to see done differently so will continue with the project.
Currently the 3rd party module service only supports exact version or master, meaning that dependencies of dependencies are either hard-coded to a version or just use master (which isn’t recommended I believe).
I have been thinking about this, I don’t like that 2 dependencies could each depend on 2 different versions of the same dependency. It’s not common in node because of the version prefixes. It might be possible to add a similar mechanism to deno.land/x, but I’m unsure how well it would work, since while ^1.0.0 and ^1.1.0 point to the same version, they would be separate URLs and be cached separately in deno. Allowing ^1 might work, but you would also have to consider that each github repo might tag versions slightly differently, which makes it difficult.
Using import maps won’t work either, since they’re for application-level development and not library-level.
Hell, you wouldn't even need the link if it's inplied it's from deno.land, you could just have syntax in package.json like
"dependencies": {
"discord.js": "^12.2.0", //implied it's from deno.land
"discord.js": "https://deno.land/MASSIVE_LINK"
}
I my main gripe is that NPM was an imperfect system, but it had really good parts about it too. If Deno had a similar package manager, lets say DPM, that
1. Had a single place to store the actual code from the users dependencies
2. Had a CLI to interact with DPM's packages, pretty much syntactically equivalent to NPM (I think Yarn's 'add' would make more sense as you're not installing it yourself, you're adding it)
3. Relies on a Package.json that everyones familar with, is easy to set up, and imo, wasn't flawed.
If you're talking about the HTTP server, it says it right in the announcement and explains why it "feels" faster.
> HTTP Server Performance > We continuously track the performance of Deno's HTTP server. A hello-world Deno HTTP server does about 25k requests per second with a max latency of 1.3 milliseconds. A comparable Node program does 34k requests per second with a rather erratic max latency between 2 and 300 milliseconds.
Dex is essentially a port of query building features of knex.js. Since Dex is a based on knex, it uses essentially the same syntax as knex, and supports the following SQL dialects:
​
​
However, Dex doesn't support query execution features since not all database drivers have been ported over to Deno yet, so you'll need to find a driver from the third party deno libraries to execute the queries.
My browser formatted this on one line, so:
import { serve } from "https://deno.land/[email protected]/http/server.ts";
const body = new TextEncoder().encode("Hello World\n"); const s = serve({ port: 8000 }); console.log("http://localhost:8000/");
for await (const req of s) { req.respond({ body }); }
What are your thoughts on import maps versus a deps.ts
file? They strike me as a nicer solution for some reason, aside from the fact that they require a command-line argument.