Big Changes Ahead for Deno

• deno

  472 98,120 10.0 Rust

  A modern runtime for JavaScript and TypeScript.

  

  The "npm:" import does not appear to have even started development, although it has been planned for a long time: https://github.com/denoland/deno/issues/13703

  Core features for npm compatibility though (like implementing most of the npm api, including require(), and its special globals) has been making progress for a long time.

  There is even a near complete project to support Node's native api (which bun also supports): https://github.com/denoland/deno/pull/13633

  Relative to the the existing node compat efforts, the url import (and accompanying package download code) will be fairly small. The most difficult part is probably the extra stuff that node throws in the global namespace. How to handle that without having to pollute the global namespace for all programs (even those that do not import from node) is unclear.

  Ideally these globals would be visible only from code in modules imported from npm. But the spec does not really allow for this unless the npm code is loaded in a different realm, but cross realm code causes a lot of headaches, which could only be avoided by having the realms share most globals and intrinsics (and sharing intrisics is not allowed by the spec).

  There may be some other way to hack this into working, or perhaps programs with such imports that actually use NPM specific objects will need to be run with the "--compat" flag. It is really unclear at the moment.

• SaaSHub

  www.saashub.com featured

  SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives

  

• deno-lambda

  8 866 7.9 TypeScript

  Discontinued A deno runtime for AWS Lambda. Deploy deno via docker, SAM, serverless, or bundle it yourself.

  

  As I had mentioned, it requires using a Lambda Layer. See: https://github.com/hayd/deno-lambda/blob/2d90756a0f18b57f16e...

  Using your own image (i.e. without using the base AWS image with the layer) you'd get even worse cold start times.

• bun

  338 74,506 10.0 Zig

  Incredibly fast JavaScript runtime, bundler, test runner, and package manager – all in one

  

• esbuild

  338 38,248 9.1 Go

  An extremely fast bundler for the web

  What you're looking for is ESBuild: https://esbuild.github.io/

• patch-package

  66 10,488 2.4 TypeScript

  Fix broken node modules instantly 🏃🏽‍♀️💨

  Does something like patch-package: https://www.npmjs.com/package/patch-package exists for Deno? If yes/no how does it work/would work?

• xgboost-node

  1 40 10.0 Cuda

  Run XGBoost model and make predictions in Node.js

  

• tsup

  26 9,289 8.8 TypeScript

  The simplest and fastest way to bundle your TypeScript libraries.

  One option is to do type checking with tsc (or in your unit tests). And build into a single file with tsup.

  https://tsup.egoist.dev/

• swc

  149 31,300 9.9 Rust

  Rust-based platform for the Web

  

• license-checker

  10 1,615 0.0 JavaScript

  Check NPM package licenses

  I don't care whether it's all in one file or in a dozen files, but I want all of that information to be available programmatically in a text file (unlike in a readme or on Github) in a standardized location in a project.

  In that respect, package.json is a strict win. Your lack of willingness to use `git blame` to see why you added a line, or lack of reasonable git comments, is not to be blamed on the file.

  Complexity is unavoidable. How could you write a tool like license-checker [1] for a Go-based project without having license information in a standardized location? Without the scripts section, how can you create a tool like husky [2] that automatically installs git hooks for a project? Every single part of package.json is there for a good reason; at best you could argue that putting some of it in other files would be aesthetically superior, but that's just bikeshedding.

  Complexity isn't de facto bad. Some complexity is required if you want a certain level of functionality to become available. Deno (and Go) are slowly accumulating that "cruft" as people realize that those functions are actually useful or even critical to a mature ecosystem.

  [1] https://www.npmjs.com/package/license-checker

  [2] https://www.npmjs.com/package/husky

• node-gyp

  26 9,971 7.7 Python

  Node.js native addon build tool

  

  I assume it's use of node-gyp, the native plugin system.

  https://github.com/nodejs/node-gyp

Suggest a related project