28 ms·

Deno 1.28: Featuring 1.3M New Modules

• grenran 4y ago
• JLCarveth 4y ago
  > No node_modules folder by default (use --node-modules-dir for backwards compatibility). Modules are cached once in a special global directory. This is definitely interesting. It will be nice not having to deal with that massive directory in each project.
  • dham 4y ago
    It's the same way every package manager has done this since the beginning of time.
    • lucacasonato 4y ago
      Well except for NPM :D
      • SparkyMcUnicorn 4y ago
        Composer also?
    • franciscop 4y ago
      Package managers end goal was the user to use the package, so it was good that they were installed globally. npm goals, as a tool for devs, includes having projects self-contained and not interfere with each other, which is pretty different goal and thus having a local node_modules has multiple advantages instead of installing everything globally. Kinda how docker or virtual machines work, but just for packages.
      • jonny_eh 4y ago
        I was under the impression that Node (and the node_modules folder) predated NPM. So NPM was just going along with the concepts laid down by Node.
    • IshKebab 4y ago
      Every system package manager. There are plenty of programming dependency managers that don't use a centralised store though.
    • singularity2001 4y ago
      except for rust which downloads the same package over and over again, even in the same project!
    • folkrav 4y ago
      I heavily disagree with the very premise that OS package managers are solving the same problems as language-specific, development targeted dependency management solutions.
      • yamtaddle 4y ago
        Language-specific package managers also often install globally, at least by default.
        • folkrav 4y ago
          Really? I know pip does it by default if you don't use virtual envs, but that's related to how pip works - activating the venv basically swaps pip/python executables and `site-packages` to the ones in the venv directory. I admittedly can't think of another I used where that's the case (none of cargo, go mod or npm/yarn/pnpm install globally by default). I admittedly did not really try others enough to notice how they work. Still, the end-goal is not the same, IMHO. Outside exceptions (e.g. some developers not packaging their applications and making users install through `pip`/`npm install -g`, which I also really dislike), your typical end-user would not interact with language specific package managers. They're most typically used for development/deployment dependencies, not end-user installation.
          • yamtaddle 4y ago
            Go's not technically global but the path of least resistance is to use it as if it is. You'll only notice the difference on an actual multi-user workstation, or if you take extra steps to get a per-project package directory. Rubygems is usually global. The granddaddy of them all, CPAN and its cpan install tool, defaults to installing globally, in practice, on most systems. Pip, as you noted, does it. I think Maven's typically user-scoped, so not really global, but also not project-scoped like npm. Similar to Go. You can get around this in most or all cases—sometimes with options or config, sometimes with extra effort or some aliases or scripts, sometimes environment variables, sometimes with 3rd party tools—but the simplest or default mode is global installation, or at least project-global if not user-global in Go's or Maven's cases. And many of those solutions (e.g. rvm) still don't scope installation per-project by default, like npm does. At the time npm got started, especially, it was definitely an outlier in its default scope. Some others have taken its approach since, and maybe a majority of total language-specific package managers even do, these days, but adjusted for actual use in the wild, I bet NPM's by far the most-used one that operates that way, and that most of the other popular ones scope more broadly—including, often, globally—by default. That is, a language-specific package manager one runs into in the real world, in 2022, usually isn't going to scope packages like NPM does without some extra effort. Global or per-user scoping (the latter being functionally identical on any single-user machine) are more likely.
  • trinovantes 4y ago
    Downside is you can't use patch-package Even the --node-module-dir flag just creates a symlink to your home directory cache so you can't do per-project package fixes (besides forking and rehosting the package) I'm also not sure how/if it supports packages that require compiling binaries like sqlite or playwright without post-install hooks
    • warent 4y ago
      This seems like a super edge case or antipattern anyway. I've worked with Node.js for several years and can't think of a time I've patched my local node_modules, because a) how would I ensure they're not overwritten in the next npm install, and b) how would I share those changes with the team
      • trinovantes 4y ago
        patch-package is a tool for this specific purpose https://www.npmjs.com/package/patch-package https://www.npmjs.com/package/patch-package You commit your changes as a diff text file and add the patch-package command to your post-install hook so it runs after every install My main use for it is fixing other packages' package.json exports field and Typescript definitions
        • warent 4y ago
          Interesting, I can definitely see this being particularly useful for typescript fixes. Where should one put the text files in the code base? Do you create some root level "patch" directory?
          • amaranth 4y ago
            patch-package automatically makes a `patches` directory at the top level of your project with `{package-name}+{package-version}.patch` files in it.
          • jitl 4y ago
            yes
  • memco 4y ago
    This sounds similar to PNPM: https://pnpm.io/ https://pnpm.io/. You still get a node_modules folder but it just has symlinks into the global cache. Ot was basically a drop-in replacement (minus the need for —shamefully-hoist on our install) and ended up being faster to install and build
• rr888 4y ago
  What was the other node alternative that was faster? I was going to try it out, but can't remember it. Deno seems too much of a change.
  • Jarred 4y ago
    I think you mean Bun https://bun.sh https://bun.sh Please share any feedback jarred@oven.sh
  • commitpizza 4y ago
    bun
  • mhd 4y ago
    Bun?[1] Which is a bigger change then Deno, as that is basically node with some more stuff included (same engine, lead developer, similar attitude towards standard library etc.), whereas Bun is using the JavaScript Core engine from Safari. [1]: https://bun.sh https://bun.sh
    • brundolf 4y ago
      Sorry, but this is nearly the exact opposite of the truth. The choice of underlying JS runtime only really affects performance. Bun is specifically designed to be fully Node-compatible (including the standard library, etc), while Deno is specifically designed to be a break that leaves Node's baggage behind (the current post is one of the pragmatic compromises they've made on that intent, but the intent is still there). Both runtimes add their own stuff on top of the above, but Bun is definitely the most "like Node" in terms of compatibility/familiarity/ease of adoption (and I say this as someone who prefers Deno).
  • yurishimo 4y ago
    Bun is probably what you're thinking of. https://bun.sh https://bun.sh
  • deleted 4y ago
    [deleted]
  • 4y ago
• commitpizza 4y ago
  I like what Deno is doing, it also has a bunch of great features. The functionality of it is great and the execution is sharp. However, my main gripe with Deno is that it's tied to one company and it won't solve issues that it doesn't have. As an example of this, a version of nodes cluster module is not supported so there is no way of running one deno process per cpu which is very bad if you're hosting it yourself and want to utilize the full potential of your hardware. It also means that if your app is bound to some CPU heavy action, like generating a large excel-file or similar, your app will go down since no requests will be processed due to the single thread nature. Of course, such actions can be solved with a web worker but what if you make a coding mistake which renders an unhandled exception? In this case the app would probably go down and if the end user for example does the same action over and over again (which end users tend to do in frustration), the app will go down again and again. Deno as a company has probably little interest in solving this as the solution is to run it on their paid service. You could of course have several servers hosting the app, but that gets expensive real quick especially if you are a small shop. Another example is to run the entire app process as web workers but then you need to spin up many processes that all have their own ports which you need to add a load balancer in front of it. This is kind of advanced and adds unnecessary complexity to the app IMO. Also, if Deno the company company fails, what then will happen to Deno the project?
  • homeland221 4y ago
    Similar with MySQL. As long as the code is open sourced...I'm ok with it...heck MySQL managed to turn into MariaDB and yet many still stick MySQL.
  • spion 4y ago
    regarding multiprocess, I think solutions such as kubernetes and similar are the way to go (rolling restarts / updates, autoscaling, advanced load balancing etc) rather than having it managed within the runtime libs > what if you make a coding mistake which renders an unhandled exception? AFAIK unlike node, Deno's API is largely promise-based and therefore all unhandled exceptions should become unhandled rejections withou crashing the process - so this should be less of an issue than it is with node (Of course, using older node libraries makes crashes more likely)
• Equiet 4y ago
  Even if you can't use Deno in your project today, it's hard not be excited about the future that Deno is pushing towards (and dragging the Node ecosystem with it). When ES6 came out but wasn't yet widely supported it became pretty common to add a build step to transpile the backend code to. This brought a whole bunch of issues that transpilation brought with it but was seen as a temporary evil worth the tradeoff because the new language features brought so many productivity improvements, but stuck for so long it became pretty standard. And when TypeScript became popular, it felt like we'll just never get rid of this complexity explosion that build systems bring. And then Deno came. Just imagine the amount of config files you'll be able to delete once you no longer need to build your backend codebase.
  • mananaysiempre 4y ago
    As always, less complexity and less expressive power at a given level go hand in hand: Deno as it exists right now can’t work even with a relatively tame nonstandard approach to JSX such as that in Solid.js[1] (without essentially running a build step at startup), let alone a full language extension like Svelte[2] (there is a thing for that now[3], but it seems to be squeezing in a build system through a localhost server IIUC?). [1] https://github.com/solidjs/solid/discussions/332 https://github.com/solidjs/solid/discussions/332 [2] https://github.com/sveltejs/svelte/issues/4431 https://github.com/sveltejs/svelte/issues/4431 [3] https://github.com/crewdevio/Snel https://github.com/crewdevio/Snel
• varispeed 4y ago
  1.3M modules... Node developers be like: "Oh that function I just wrote is so beautiful, let's make a module!"
  • deleted 4y ago
    [deleted]
  • frou_dh 4y ago
    https://twitter.com/steveklabnik/status/1100978262875037701 https://twitter.com/steveklabnik/status/1100978262875037701
    • naikrovek 4y ago
      this is exactly why the unix philosophy is flawed. this is not a flex.
      • mi_lk 4y ago
        Except that the philosophy is beautiful and extremely useful due to composability It's those random lib authors who take the philosophy too literal that fail the community
        • naikrovek 4y ago
          > Except that the philosophy is beautiful and extremely useful due to composability The philosophy is beautiful on the surface, which is exactly how far beauty extends. Write some load-bearing software using a litany of software all connected by pipes throwing untyped text streams around to various handles. If you do this, and you do not experience problems due to composability, one of the following is true: 1) you aren't doing real work, 2) your software exists in an environment which never changes, which is very rare for most people (meaning that you have fixed your environment enough to wallpaper over problems with composability.) statically compiled stuff and strongly typed data is the only way to longevity that is worth the time you need to put in to a system that must work.
      • 4y ago
• msoad 4y ago
  Really impressed with Deno's overall vision and execution. They are taking the slow and steady road. I remember everyone criticizing them for not supporting npm at the start but I was sure at some pint it has to happen. You can't live without the npm ecosystem if you are writing code in javascript. I am still not using Deno as my main production runtime but at some point I might make the switch. Personally I'll use Deno if I can use it with Next.js which with this npm development I can see Next.js support coming soon. Next.js and Deno are both focused on executing code on the edge so it's just natural for it to happen. Great work Deno team! You deserve all the credits!
  • nonethewiser 4y ago
    Seems like Deno's answer to Next.js is Fresh. Wouldnt it be on Next.js to make themselves compatible on Deno? Either way, it doesnt seem like either party has too much incentive to make this work.
    • msoad 4y ago
      Fresh is nice. So is Deno without npm. But it's always about the ecosystem. If Deno wants adoption they should invest in making Deno an option for new Next.js projects
    • Escapado 4y ago
      I am not sure if Fresh would be a direct competitor since it does not and will not[0] support client side routing. In every company I worked for in the last few years white flashes on page navigations were absolutely unacceptable. I still like the framework, but it probably targets a more specific segment of the market. I think aleph.js[1] is more like next and then there is the esoteric ultra.js[2] which kind of tries to do something similar and be super bleeding edge. [0] https://github.com/denoland/fresh/issues/403#issuecomment-1176089378 https://github.com/denoland/fresh/issues/403#issuecomment-11... [1] https://github.com/alephjs/aleph.js https://github.com/alephjs/aleph.js [2] https://ultrajs.dev/docs https://ultrajs.dev/docs
  • brundolf 4y ago
    I'm wondering if Vercel itself has interest in Deno, given their focus on the edge (and generally being at the forefront of JS tech). I hope they don't try and purchase it or anything, but first-party Next.js support for Deno would be awesome
• ddmma 4y ago
  Migration tool from NodeJs
• rickstanley 4y ago
  > Building apps will be easier and _more secure than ever_ I assume it is because of the permissions feature of Deno. If so, at what extent(s) does Deno provide security if I have a deep, deep [npm] dependency that, for instance, reads file, i.e. needs file system permission? Do I have to specify every single permission for each dependency? Does Deno have some kind of "dependencies file" that allows to specify dependencies' permissions? See: https://news.ycombinator.com/item?id=30703817 https://news.ycombinator.com/item?id=30703817
  • rickstanley 4y ago
    I can see at: https://deno.land/manual@v1.28.0/basics/permissions https://deno.land/manual@v1.28.0/basics/permissions, that I can set permissions through parameters.
  • amaranth 4y ago
    As far as I know permissions are at a process level, not a module/dependency level. This means if something in your application needs to be able to read/write a file then all of your dependencies can as well.
• afavour 4y ago
  I feel conflicted about this. It makes 100% sense for Deno to do this from a business and marketshare standpoint: they need those modules in order for people to make the kind of projects they're making with Node. But I was really hoping that Deno would be a reboot: flush out all the awful NPM modules out there you don't even know you have a dependency on and create a JS module ecosystem worth its salt. In some ways "1.3M new modules" is more scary than impressive. But alas, here we are. We've got the JS ecosystem we deserve.
  • deleted 4y ago
    [deleted]
  • jbaczuk 4y ago
    If the new js module ecosystem really is better, then js developers would publish new modules there instead of npm, and eventually legacy modules on npm would be migrated over. I don't think that is the issue. You don't have to use NPM to use deno, it's just an option. But yes, NPM is scary.
    • afavour 4y ago
      Yes but people usually follow the path of least resistance. If modules are on NPM they'll stay on NPM if there's little incentive to rewrite as ESM isomorphic modules and publish for Deno.
      • jbaczuk 4y ago
        yes, exactly. There needs to be more incentive
        • tomcam 4y ago
          How would that happen?
          • jbaczuk 4y ago
            by improving the js module ecosystem enough. I don't know if that's possible, it seems like more of a behavior change than technology.
• SyrupThinker 4y ago
  I’m slightly disappointed that the vision of leaving NodeJS and npm behind ended up failing. The last year ended up being a bunch of concessions to make Deno more appealing to the masses, like disabling type checking on run by default. But hey, that’s pragmatism for you, sometimes you just have to let go of ideals even if it hurts a bit. I’m certainly looking forward to what happens next, even if more from the sidelines.
  • Already__Taken 4y ago
    npm has a lot of issues and I don't think the credit for adding value is delivered with the flack it gets. Everyone's darling Python is still garbage to figure out packaging and deploying even with supposedly great new poetry compared to npm.
  • capableweb 4y ago
    > But hey, that’s pragmatism for you, sometimes you just have to let go of ideals even if it hurts a bit. But on the other hand, that's how we end up with a programming language landscape where every language is mostly the same, except for community conventions and very slightly different syntax. I'd love it if more languages where strongly controlled like Clojure and alike, where there is a unified vision that is well kept across time. Not that Clojure is perfect, but probably the best example of a language where the community is welcome to suggest things but unless the person in control approves it, it won't make it into the core language and instead will/could be implemented as a library. In contrast to Rust which seems to base language additions/changes based on popularity in the community.
    • pie_flavor 4y ago
      JS is JS. It's not going to stop being JS. Deno is a slightly different syntax for the same thing. If you want a different language, step 1 is to pick a different language.
      • capableweb 4y ago
        JavaScript in 2022 is JavaScript in 2022, but won't be JavaScript 2022 won't be the same as the JavaScript we'll have in 2030, nor was it the same JavaScript we used in 2010. That's because JavaScript is not driven by a single person with a unified vision, it's driven by a committee who implements stuff based on popularity, quite literally. I don't want a different language, I want multitude of different languages. And not a multitude of different Fortrans/C-like language.
• tylermcginnis 4y ago
  "You can now import over 1.3 million npm modules in Deno". Pragmatism prevails.
• hit8run 4y ago
  How can one use a bazillion modules in production and not get hacked because of a dependency vulnerability? How are packages vetted?
  • simlevesque 4y ago
    You can control the security to allow only certain ip addresses to be accessible, control which folders is readable or writable, decide if Deno can access hrtime which could be abused to fingerprint you and more: https://deno.land/manual@v1.27.0/getting_started/permissions https://deno.land/manual@v1.27.0/getting_started/permissions
• Piegie 4y ago
  Unless I'm missing something, does the lack of an 'install' command (be it for non-npm or npm libraries so you can bundle the packages with your image) not mean it's detrimental to any deployment where you have either horizontal scaling or cold starts (eg. GCP Cloud Run)?
  • deleted 4y ago
    [deleted]
  • Piegie 4y ago
    Ah, there is this: https://deno.land/manual@v1.28.0/advanced/continuous_integration#caching-dependencies https://deno.land/manual@v1.28.0/advanced/continuous_integra..., however I can't seen to find any specific page for a 'deno cache' CLI command aside from some loosely related pages that use the command.
  • dsherret 4y ago
    The `deno cache` command (ex. `deno cache main.ts` or `deno cache --node-modules-dir main.ts` if you want a node_modules folder) will ensure all npm packages used in the provided module are cached ahead of time. It acts similarly to a `npm install` if you need it. Also, at the moment, npm specifiers aren't supported with `deno compile` (https://deno.land/manual@v1.28.0/tools/compiler https://deno.land/manual@v1.28.0/tools/compiler), but in the future that will be one way to have a self contained executable with everything ready to go.
  • simlevesque 4y ago
    To deploy you'd create a binary executable version of the whole project and deploy that. That's what Deno Deploy does, I think. This way the execution is almost garanteed to me the same and the edge network doesn't have to support the runtime at all, just allow binaries. https://deno.land/manual/tools/compiler https://deno.land/manual/tools/compiler
• CPUTranslator 4y ago
  I am by no means a JavaScript person; I use it when it’s the right tool for job (rare). However, projects like Deno and Bun make me hopeful for the future of the JS ecosystem. And while the ‘1.3M modules’ headline is more scary than exciting (for me), I’m glad they locked it behind a special “npm:” classifier and have their own way of dealing with node_modules so things stay explicit, while allowing people to swap over somewhat seamlessly. I wonder what impact this will have on Deno and NPM long term.
  • jalino23 4y ago
    whats your go to language?
• gosukiwi 4y ago
  So what's the difference between Deno and Bun? Are they just drop-in node replacements?
  • richeyryan 4y ago
    Both Bun and Deno aim to be batteries included, shipping Typescript and a test runner etc., by default. Deno initially aimed to diverge from Node and conform to the web platform as much as possible, i.e. use ES Modules and Web APIs over custom APIs. They've moved back towards Node over the last while to get more adoption. Bun broadly aims to be Node compatible, but they seem to try to stick to Web APIs too. Bun seems to value performance as a primary concern, with start-up time being an often-discussed metric. The value being improvements to local developer toolchains or fast starts in edge environments. Deno seems to value developer experience, with the goal being an overall better Node. They also benchmark performance against Node and seem to be faster in some places but not others. Finally, Bun uses the JavaScriptCore engine from Webkit, which it seems can be faster than V8 in some situations. This is the perspective of a relatively detached observer who has played with both a little and kept up with their development somewhat but hasn't done a serious project with either.
  • Jarred 4y ago
    Bun is an all-in-one JavaScript/TypeScript bundler, runtime, package manager, and transpiler focused on being being fast and a drop-in replacement for Node. Much of it is written from scratch in Zig. Bun also adds many runtime APIs like a builtin websocket server, FFI, Bun.mmap, SQLite, Bun.Transpiler and more. `bun dev` let’s you use bun’s transpiler for frontend code `bun install` is an npm client you can use with Node and it installs packages 20x - 100x faster than npm/yarn/pnpm `bun run` let’s you run package.json scripts really fast (I work on Bun)
• rubenfiszel 4y ago
  If you want to play with deno in the browser with LSP support and instant preview, no need to install anything. Signup on https://app.windmill.dev https://app.windmill.dev -> New Script -> Next, that's it you can now play with deno and get a feel of the language and auto npm imports.
  • qbasic_forever 4y ago
    How is this easier than actually using deno? It's a single executable. Download, write code in your editor of choice and run deno. No account sign up, no install, no friction.
    • guhidalg 4y ago
      Did you forget the /s? You're implying that 1. downloading an executable 2. opening an editor 3. writing and saving a file 4. running the executable Is somehow easier than opening a website writing some code and pressing run?
      • qbasic_forever 4y ago
        You have to sign up for an account which means waiting for and then verifying an email. In addition to giving your mail up for spam and bullshit from a startup that I could care less about. Hard pass, I'll download an exe and run it.
      • wiseowise 4y ago
        > Is somehow easier than opening a website writing some code and pressing run? Faster than opening website - no. Faster than opening website, signing up, verifying email, saving password - absolutely.
• deleted 4y ago
  [deleted]
• adamddev1 4y ago
  support for next.js soon??
• singularity2001 4y ago
  The new npm import is a much required step in the right direction. The next step would be to allow namespacing of other / default repositories. ``` import namespace npm import { chalk } from "chalk" import { assert } from "test" … import namespace local import { chalk } from "mychalk.ts" import { assert } from "test" // who needs extensions anyways? ```
  • brundolf 4y ago
    a) They intentionally want to segregate NPM imports, because this is a stopgap, not the way forward they're trying to lay out for the ecosystem. The future Deno is aiming for is one where you don't have repositories (as we've known them), only web domains. b) The above introduces non-standard JS syntax and semantics, which also goes against Deno's philosophy
    • singularity2001 4y ago
      b) that's a valid argument. so Deno.namespace("npm") would be the way a) that's fine. In fact namespacing helps with segregation, because once there is some "npm for deno" one would just set the appropriate Deno.namespace("default") without having to touch a million import "npm:package_xyz". Explicitly repeating full paths such as import { createRequire } from "https://deno.land/std/node/module.ts https://deno.land/std/node/module.ts"; over and over again is just an ugly antipattern.
      • brundolf 4y ago
        My opinion is that imports are such a simple, rarely-modified, hard to mess up (and often automatically-managed) part of the code that it's much more valuable to have simplicity/explicitness over complex new mechanisms that save a few characters. But we can agree to disagree Another thing that helps is that in Deno, it's common to have a deps.ts file that imports and then exports all the third-party libraries in use, for the rest of the project to reference. This is mainly done to make sure everything is using the same versions of everything, but it helps with brevity too. You could even approximate your own namespacing mechanism using this pattern
• andrewstuart 4y ago
  Can I use Deno now with AWS from npm and everything just works?
  • simlevesque 4y ago
    Yes, `import { S3Client } from 'npm:@aws-sdk/client-s3@3.209.0'` works. Not every module work perfectlym but newer modules almost always do. If it's a ESM module, you won't shouldn't have any problems.
• singularity2001 4y ago
  Edit: can't delete, but thanks for finding typo https://www.npmjs.com/package/binaryen https://www.npmjs.com/package/binaryen
  • simlevesque 4y ago
    The error is pretty much self explanatory. The npm package 'binaryan' does not exist. https://www.npmjs.com/package/binaryan https://www.npmjs.com/package/binaryan returns a 404. The package you try to import must exist on npm.
• flanbiscuit 4y ago
  I can see merit in both sides of the argument on whether Deno should have added npm support. I lean towards the side that's excited about this release, especially for what's mentioned here: https://deno.com/blog/v1.28#security https://deno.com/blog/v1.28#security deno run npm:install-malware ┌ Deno requests write access to /usr/bin/. ├ Requested by `install-malware` ├ Run again with --allow-write to bypass this prompt. └ Allow? [y/n] (y = yes, allow; n = no, deny) > This alone would entice me to start using Deno as a drop-in replacement for Node (I'm mostly running it to bundle front-end things).
• circuit8 4y ago
  I literally only just realized that Deno is an anagram of Node...
  • JSdev1 4y ago
    'node'.split('').sort().join('') == 'deno'