deno_std
LavaMoat
deno_std | LavaMoat | |
---|---|---|
17 | 16 | |
1,038 | 819 | |
- | 2.1% | |
0.0 | 9.8 | |
over 4 years ago | 1 day ago | |
TypeScript | JavaScript | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
deno_std
- Ask HN: Where do I find good code to read?
-
[Showcase] My first project in Deno and an early perspective
For reference (for the issues you mentioned): 1. This issue was opened almost immediately to solve the weird .only function not working https://github.com/denoland/deno_std/issues/2979 2. That looks weird to me, will get back to you on this one since it should work I think 3. Generally polluting the global namespace isn't great, but because we're only polluting the namespace of a module (and we choose what parts to import), I personally find it quite freeing. I entirely understand how that might feel awkward. 4. you CAN specifying only writing to certain directories! --allow-write=/path/to/dir would allow that!
-
Deno v1.27
At least for the ones related to trees, it's just a renaming. Below is a link to the PR. When I initially implemented these trees, I chose the names BSTree and RBTree to keep the names short. I'm guessing the person that proposed renaming them did so to make it more obvious what they are.
https://github.com/denoland/deno_std/pull/2400
The standard library is separate from the runtime. It wouldn't break backward compatibility if you were to update. For example, if you were importing RBTree and upgraded Deno to the latest release, it would keep working just fine. You would only really need to switch to using RedBlackTree instead if there was a change made to it that you wanted.
I think the only time you would need to update your standard module imports to be able to use newer versions of the Deno runtime if the standard module were depending on runtime APIs that have a breaking change.
-
No Safe Efficient Ways to Do Three-Way String Comparisons in Go
It is like Demo deprecating fs.exists().[1]
[1]https://github.com/denoland/deno_std/discussions/2102
-
Programming language comparison by reimplementing the same transit data app
This was fun to read through.
I would need to profile the code, but the startup time being bad for Deno seems like maybe a combination of the code in here being unoptimized:
https://github.com/denoland/deno_std/blob/0ce558fec1a1beeda3...
(Ex. Lots of temporaries)
And usage of the readFileSync+TextDecoder API instead of readTextFile (which is also a docs issue since it's suggests the first one). It seems the code loads the 100MB into memory, then converts to another 100MB of utf8, then parses with that inefficient csv decoder. The rust and go versions look to be doing stream/incremental processing instead.
-
How do I check if a file doesn’t exist?
But it there's some talk to reconsider it
- JSWorld Conference 2022 Summary - 1 June 2022 - Part I
-
Testing frameworks
Sorry to hear that. I want to provide expect API in deno_std in the future: https://github.com/denoland/deno_std/issues/1779
-
Just migrated my first module from Node to Deno: Froebel - a strictly typed TypeScript utility library.
I just migrated the module to Deno and rewrote the test cases using the Deno test runner. Also contributed a bug fix to the test runner that I encountered during the migration. An npm version is still available and automatically generated from the Deno code via a small bash script (rewriting imports, adding an index.ts, etc.).
-
Deno.js in Production. Key Takeaways.
Much of Node.js is written in C, yet it's still called Node.js.
Deno has some JavaScript/TypeScript in it. On GitHub https://github.com/denoland/deno is 22.8% JavaScript and 13.2% TypeScript, and https://github.com/denoland/deno_std is 68.2% JavaScript and 31.6% TypeScript.
So to me it's misleading about the name, but not about what Deno is written in.
LavaMoat
-
Ledger's NPM account has been hacked
Just yesterday I watched a talk [0] at WarsawJS about LavaMoat [1], a set of tools to protect against malicious behaviour from npm dependencies. Guess it’s time to look into it deeper.
[0]: https://naugtur.pl/pres3/lava/2023end.html
[1]: https://github.com/LavaMoat/LavaMoat
-
Dozens of malicious PyPI packages discovered targeting developers
You are basically talking about Lavamoat. It provides tooling and policies for SES, which aims to make it into standards.
https://github.com/LavaMoat/LavaMoat
-
Supply chain security - prevent, not avoid
Enter: lavamoat. https://github.com/LavaMoat/LavaMoat
- LavaMoat: Tools for sandboxing your dependency graph
-
Deno.js in Production. Key Takeaways.
You should check out Lavamoat: https://github.com/LavaMoat/LavaMoat
It attempts to do what you're essentially describing. It was built by the MetaMask team, where supply chain attacks are an obviously huge risk.
I've spent some time trying to get it working in an app, but haven't been able to get it all the way working. It's still pretty beta and not well documented.
- Node.js packages don't deserve your trust
-
How to respond to growing supply chain security risks?
And it is happening right now. Github is opening the GitHub Advisory Database to community submissions. Awesome community NodeSecure builds cool things like scanner and js-x-ray. There are also lockfile-lint, LavaMoat, Jfrog-npm-tools (and I am sure there is more).
- On node-ipc and the importance of trusting trust
-
NPM package compromised by author: erases files on RU / BY computers on install
There is a proposal to add OCAPs on a language level in TC39[0]. There is already a drop-in implementation which already works in both Nodejs and browsers[1].
As a developer who wants to sandbox your own (recursive) dependencies, this is made accessible today in Lavamoat[2]. Basically a package or app can provide a policy manifest specifying which capabilities (e.g. network or filesystem access) should be granted for each dependency. Also comes with a tool that will auto-generate a starting point from your existing dependency tree.
IMO this is the future. Currently it does come with a performance penalty but hopefully this idea will catch on and make it into runtime implementations.
Lavamoat is still marked as "preprod" on npm but talking to the author it's a matter of days or weeks until the first stable release.
[0]: https://news.ycombinator.com/item?id=30703817
[1]: https://github.com/endojs/endo/tree/master/packages/ses
[2]: https://github.com/LavaMoat/LavaMoat
- Node runtime that sandboxes all NPM dependencies by default
What are some alternatives?
fp-ts - Functional programming in TypeScript
metamask-extension - :globe_with_meridians: :electric_plug: The MetaMask browser extension enables browsing Ethereum blockchain enabled websites
froebel - A strictly typed utility library.
create-vue - 🛠️ The recommended way to start a Vite-powered Vue project
Refactoring-Summary - Summary of "Refactoring: Improving the Design of Existing Code" by Martin Fowler
vue-cli - 🛠️ webpack-based tooling for Vue.js Development
clara-rules - Forward-chaining rules in Clojure(Script)
cli - the package manager for JavaScript
intellij-lsp-server - Exposes IntelliJ IDEA features through the Language Server Protocol.
handlebars-helpers - 188 handlebars helpers in ~20 categories. Can be used with Assemble, Ghost, YUI, express.js etc.
pocket - Official implementation of the Pocket Network Protocol v1
EventSource - a polyfill for http://www.w3.org/TR/eventsource/