”工欲善其事,必先利其器。“—孔子《论语.录灵公》
首页 > 编程 > 探索用于 JavaScript 模块管理的 JSR

探索用于 JavaScript 模块管理的 JSR

发布于2024-07-31
浏览:172

Written by Oyinkansola Awosan✏️

JavaScript has become the most widely used programming language in the world. Whatever you can imagine that you want to program, JavaScript is typically the go-to language. It's functional for programming just about anything, a reputation that hinges on its ability to run on servers, mobile devices, robots, browsers, and more.

You can hardly discuss JavaScript’s successful track record without mentioning the npm package registry used to manage reposited JavaScript packages. With about 2.5 million packages and billions of downloads, npm is the most successful software registry ever by most metrics.

Of course, this is not to say that npm has been the only functional registry since its creation more than 10 years ago. It has only stood out from the rest with its value proposition more than its functionality.

However, npm has been long overdue for a “successor.” The JavaScript community can use a new registry, one that is better designed to suit present-day programming needs. In this article, we’ll introduce the JavaScript Registry (JSR), Deno’s open source package registry for modern JavaScript and TypeScript.

A brief review of software registry systems

First, let’s go through a high-level overview of the concept of registries to provide context to the JSR review.

Registries are spaces provided as banks for third-party packages. Currently, npm is the default registry for most JavaScript and TypeScript packages. It’s home to millions of private and public packages. The idea behind registries is to provide developers with materials to solve simple programming problems and a library to publish their packages.

Registry systems are usually operated as open source libraries that benefit from many contributors, which accounts for their high quality. In addition to the npm registry, the JavaScript ecosystem has a new TypeScript and JavaScript registry: JSR.

Introducing the JavaScript Registry (JSR)

Like npm, JSR is designed to serve as a registry for both JavaScript and TypeScript packages. JSR was also designed as an upgrade to the features provided by npm. The registry is open to all and can be accessed via the public beta platform.

JSR stores packages and is mostly a registry for JavaScript modules. It has adopted the ES module standard and other recent JavaScript innovations to accommodate current programming demands.

This upgrade to the coding experience means JSR is the place to publish JavaScript with native TypeScript support. You can write code without transcompilation before forwarding packages to the registry, enabling programming with reusable JavaScript code.

Furthermore, JSR uses more contemporary guidelines and approaches to address the shortcomings and inefficiencies of conventional package managers. JSR seeks to make module management procedures faster, safer, and aligned with contemporary JavaScript techniques.

Modern web developers finds JSR a desirable substitute since its design emphasizes eliminating redundancy, raising performance, and strengthening security. It’s a more sophisticated module management tool for handling dependencies and JavaScript modules that exceeds expectations and surpasses conventional package managers like npm, Yarn, or pnpm.

This detailed article delves deeper into JSR by examining its main ideas, benefits, and uniqueness compared to other common package managers. This guide will clarify why many consider JSR to be the future of JavaScript module management.

Why use JSR?

We’ve talked a little bit about why JSR was developed and how it improves on the experience of other package managers. Now, let’s get a bit more specific.

DX improvements

JSR improves on the developer experience in the following ways:

  • Auto-generated documentation — Once you publish your package, JSR will continue automatically generating documentation using your JavaScript document. This eliminates the need to run a different doc site to maintain your package
  • Package scoring system — JSR provides its users with individualised scores for each package. The score rates on different packages encourage best practices when publishing packages and users are informed about the packages they wish to explore
  • Runtime compatibility labels — JSR is designed to work with multiple runtimes. Given its compatibility with npm, JSR is compatible with any npm runtime like Node, Bun, Cloudware Workers, Browsers, etc. However, JSR is designed with Deno as its native TypeScript runtime. This does not stop the functionality of other runtime labels while using the registry. Runtime compatibility labels make it easier for users to tell clearly which runtime a package is for.
  • Better auditability — With JSR’s ES module-only design, you get direct access to a package‘s source code, not transcompiled and minified files, which enhances auditability
  • Reduced redundancy — One of the most important components of JSR is dependency management, which does not allow for redundancy. Redundancy has historically been a challenge for package managers, as they usually produce large node modules loaded with several copies of the same dependencies. JSR fixes this by using a more efficient resolution method that eliminates pointless duplicates, producing smaller project folders that are much more under control.
  • Quick installation — JSR’s enhanced performance reduces the installation time for packages and improves dependability management. Furthermore, JSR helps developers concentrate on feature development by removing redundancy and applying intelligent methods, saving them from waiting for dependability resolution

As you can see, features like reduced redundancy, improved security, and ES modules allow JSR to greatly improve the DX. This guarantees that projects remain secure and performant, lowers the possibility of running into issues, and helps handle dependencies using JSR.

Managing traditional package managers' drawbacks

Although npm, Yarn, and other conventional package managers have greatly helped grow the JavaScript ecosystem, they also have certain downsides:

  • Redundancy and bloat — Many times, these traditional package managers produce huge Node modules with tons of needless dependencies — some even duplicated — consequently bumping up the project size
  • Performance overhead — Dependency installation and resolution can be time-consuming for large applications
  • Security concerns — Dependency security has become a major difficulty as the package count increases

JSR addresses these problems by applying more effective module management techniques leveraging contemporary JavaScript standards and practices.

Adopting ES modules

Adopting ES modules makes JSR exciting since ES modules offer various benefits over CommonJS, which has been the default for Node.js. Let’s see a few examples of what makes adopting ES modules a big win for JSR and the JavaScript developer community:

  • Browsers and contemporary JavaScript engines naturally support ES modules, negating the requirement for bundlers or transpilers
  • ES modules allow for the static analysis of imports and exports, supporting improved tools and optimization
  • The stationary structure of ES modules helps shake trees more efficiently, lowering bundle sizes by omitting useless code

The deep integration of JSR with ES modules guarantees that developers can easily use these advantages, producing more manageable and efficient codebases.

JSR’s approach to module management

JSR's module management style centers on the following basic ideas:

  • Rapid resolving dependencies — The JSR dependency resolution technique is more creative than others because it guarantees that dependencies are resolved most effectively and lowers redundancy. Therefore, it produces smaller node_modules directories and faster installation times
  • Enhanced security measures — Modern software development depends critically on security. Among JSR's security capabilities include verifying package integrity ensures that the installed packages have not been altered, along with frequent automatic scanning of dependencies for known vulnerabilities and generating actionable notifications
  • Smooth ES module integration — ES modules support has been included from the ground up in JSR. This means we can use modules specified using standardized ES module syntax without needing any additional setup, which can be annoying and slow down the development process. Furthermore, this guarantees compatibility for the browser, Node.js, other JavaScript runtimes, and other environments
  • Much-improved performance — A core focus of JSR is performance; it greatly reduces the time needed to install and control dependencies by reducing duplicates and using efficient algorithms for dependability resolution

Exploring the growth and maturity of JSR

JSR has continued changing ever since it first attracted developers with its original approach and clear advantages. Early adopters valued increased security measures, faster installation times, and less redundancy in node-modules directories. These benefits were notably appreciated by people working on large-scale projects where security and efficiency are vital.

Moreover, including ES modules in Node.js systems and browsers hastened JSR's expansion. Native support for this module system became a key component of JSR's package manager as more projects turned toward ES modules, simplifying the task of module management without needing to configure additional tools and settings.

JSR evolved from a developing package manager into a dependable one some years later. The team changed its design to accommodate more sophisticated use cases and modified its features in line with feedback and pragmatic examples.

These changes resulted in more people engaged in development and sharing best practices associated with JSR among other communities. This innovation and ongoing development enables developers to match the evolving needs of the JavaScript ecosystem.

Present and future possibilities of JSR

JSR shows the great possibilities of modern module management for innovative development. It has become a reliable resource for many programmers who want to control dependencies effectively and without the problems often seen in other registry systems.

The current JSR version provides native ES module support and intelligent dependency resolution with increased security measures. These features enhance the developer experience, so JSR is better for contemporary JavaScript projects.

Regarding what’s ahead, JSR has good potential for expansion and addressing new issues as the JavaScript ecosystem changes. Extending its ecosystem could allow JSR to provide a more harmonious, simplified development experience.

Improving JSR’s compatibility with other tools or platforms is one area where more effort is needed. This entails further merging with common build systems, development environments, and CI/CD pipelines.

Enhancing scalability and performance is another crucial area for future development. Knowing how JSR systems can efficiently manage dependencies as their complexity and scale change will be crucial. Further removing redundancies and constantly optimizing the dependency-resolving technique will guarantee that JSR remains a reasonable choice for big projects.

In the future, the JSR team wants to provide more advanced security choices, like automatic updates of important security patches and real-time dependency vulnerability monitoring. These modifications will help developers maintain safe codebases and lower possible dangers.

Besides this, the JSR team is working on creating a vibrant and dedicated community. Investing in the community would allow JSR to steadily increase contributions by developers across the world, support development efforts with thorough documentation and customer support, and building a robust ecosystem that would encourage innovation and cooperation.

It will be important for the JSR team to embrace projects like plugins, extensions, and other community creations to improve its capabilities and make it sustainable.

JSR vs. other package managers

To get a better understanding of JSR's advantages, let’s compare it with well-known package managers such as npm, Yarn, and pnpm. Although overall impressive, these traditional package registries have various benefits and drawbacks that are important to consider to make more informed decisions:

npm Yarn pnpm
Description For many years, Node.js used npm as its default package manager. It offers a massive collection of packages, which streamlines looking for outside libraries. Facebook created Yarn, a package manager, to fix some of NPM's problems. It provides faster, safer, and more dependable dependency management. pnpm is another package manager designed for speed and efficiency. It uses an innovative method of handling dependencies, reducing redundancy, and boosting efficacy. It is also similar to npm. Let us quickly take a brief dive into the strengths and drawbacks of pnpm.
Strengths Boasts one of the biggest JavaScript package registries, giving developers many choices. Many users use Node.js as their default package manager, so npm’s popularity is backed by JavaScript community members. Incredibly user-friendly and requires no particular prior knowledge. Its commands are clear-cut, even for a novice wishing to install, update, or manage packages. Thanks to its parallelized dependency resolution, Yarn has come to provide rapid installation time. Deterministic installs — This ensures that the same dependencies are installed even in different contexts, lowering "works on my machine" problems. Yarn adds various security and dependability-boosting elements, such as package integrity verification and offline caching. Great efficiency — Using a content-addressed storage approach helps to reduce repeated copies of dependences through pnpm, hence reducing the size of node module directories. Relatively fast — It is commonly known that pnpm has an efficient dependency resolution system and fast installation times. Deterministic installations — Like Yarn, pnpm guarantees consistent installation of dependencies across many environments.
Drawbacks Duplicate copies of dependencies cause bloat by expanding the size of the node modules directory. Speed — Particularly on big projects, dependability resolution and installation could take some time. Safety — While the security system has advanced, maintaining the integrity of every dependent still presents a great challenge. Although Yarn has numerous functionalities, it might be more difficult to set up and utilise than npm. Redundancy — Yarn can still result in big node module directories even if it eliminates some redundancy issues. Adoption — pnpm is less extensively embraced than npm or Yarn, which can result in less community support even as it is becoming more well-known. Certain tools and libraries may not be compatible with pnpm. Thus, an extra setting is needed.

Conclusion

JSR was created to better suit the programming climate in 2024 in a way that npm could not. It’s not designed to fork npm, but to work alongside it. Designed to be cheap, JSR operates on cloud services and aims to be community-moderated and managed over time, according to its creators.

Managing JavaScript modules has come a long way with JSR. Embracing contemporary standards like ES modules makes JSR a more efficient, safe, and simplified method of dependency management that addresses the restrictions of conventional package managers.

Using JSR is a smart decision if you’re trying to maximize your processes. Its intelligent dependability resolution, expanded security features, and other features enhance the DX as well as project performance.

Although conventional package managers such as npm, Yarn, and pnpm have served the developer community well, JSR's creative approach and close connection with modern JavaScript techniques rank highest among module management moving ahead.

Adopting JSR will help developers enjoy lower redundancy, faster installation times, and a safer development environment, resulting in better maintainable and scalable systems. Over time, JSR will continue to prove why it’s the best choice for faster and safer development, particularly regarding package installation and usage.


Are you adding new JS libraries to build new features or improve performance? What if they’re doing the opposite?

There’s no doubt that frontends are getting more complex. As you add new JavaScript libraries and other dependencies to your app, you’ll need more visibility to ensure your users don’t run into unknown issues.

LogRocket is a frontend application monitoring solution that lets you replay JavaScript errors as if they happened in your own browser so you can react to bugs more effectively.

Exploring JSR for JavaScript module management

LogRocket works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store. Instead of guessing why problems happen, you can aggregate and report on what state your application was in when an issue occurred. LogRocket also monitors your app’s performance, reporting metrics like client CPU load, client memory usage, and more.

Build confidently — start monitoring for free.

版本声明 本文转载于:https://dev.to/logrocket/exploring-jsr-for-javascript-module-management-5hho?1如有侵犯,请联系[email protected]删除
最新教程 更多>
  • 大批
    大批
    方法是可以在对象上调用的 fns 数组是对象,因此它们在 JS 中也有方法。 slice(begin):将数组的一部分提取到新数组中,而不改变原始数组。 let arr = ['a','b','c','d','e']; // Usecase: Extract till index p...
    编程 发布于2024-12-21
  • 如何创建 100% 高度并隐藏滚动条的全屏 Iframe?
    如何创建 100% 高度并隐藏滚动条的全屏 Iframe?
    全屏iframe高度为100%查询:是否普遍支持iframe height=100%跨浏览器?当使用XHTML1作为doctype时,高度为100%的iframe是否会占据页面剩余高度(不包括顶部的50px固定高度框架)?另外,如何在自动设置 iframe 高度的同时完全隐藏滚动条?响应:虽然可以采...
    编程 发布于2024-12-21
  • 如何在 PHP 中组合两个关联数组,同时保留唯一 ID 并处理重复名称?
    如何在 PHP 中组合两个关联数组,同时保留唯一 ID 并处理重复名称?
    在 PHP 中组合关联数组在 PHP 中,将两个关联数组组合成一个数组是一项常见任务。考虑以下请求:问题描述:提供的代码定义了两个关联数组,$array1 和 $array2。目标是创建一个新数组 $array3,它合并两个数组中的所有键值对。 此外,提供的数组具有唯一的 ID,而名称可能重合。要求...
    编程 发布于2024-12-21
  • 如何解决 VS2010 中混合 C 和 C++ 项目中的 LNK2001 链接器错误?
    如何解决 VS2010 中混合 C 和 C++ 项目中的 LNK2001 链接器错误?
    解决 VS2010 中混合 C 和 C 项目中的链接器错误问题描述将 C 代码集成到不同 VS2010 项目中的 C 项目中导致从 C 代码调用 C 函数时出现链接错误。该错误标识为 LNK2001,与未解析的外部符号有关。解决方案要纠正此问题,请遵循特定准则来确保代码库的正确组织: 模块化代码:每...
    编程 发布于2024-12-21
  • 如何在.NET MySqlCommand中启用MySQL用户定义变量?
    如何在.NET MySqlCommand中启用MySQL用户定义变量?
    在.NET MySqlCommand中使用MySql用户定义变量在.NET MySqlCommand中执行涉及用户定义变量的MySQL语句时,您可能会遇到致命错误。要解决此问题,请按照下列步骤操作:在您的代码中,您有一条 MySQL 语句,用于设置用户定义的变量“@a”,然后选择其值。但是,您在尝试...
    编程 发布于2024-12-21
  • 如何在 Windows 版 XAMPP 中升级 PHP:分步指南
    如何在 Windows 版 XAMPP 中升级 PHP:分步指南
    在 XAMPP for Windows 中升级 PHP:综合指南在 XAMPP for Windows 中升级 PHP 对于维护安全性、功能和性能至关重要您的网络应用程序的兼容性。本指南将提供成功升级 PHP 的分步过程。从 PHP 官方网站降级您可能尝试过直接下载最新的 PHP来自 PHP 官方网...
    编程 发布于2024-12-21
  • 如何可靠地确定我的 PHP 脚本是从命令行运行还是通过 HTTP 运行?
    如何可靠地确定我的 PHP 脚本是从命令行运行还是通过 HTTP 运行?
    确定 PHP 中的命令行执行还是 HTTP 执行PHP 脚本开发中的一个常见任务是确定执行环境的类型,无论是该脚本通过命令行或通过 HTTP 运行。这些知识对于制定输出格式决策和相应地自定义行为至关重要。检查 SERVER['argc'] 是否存在的传统方法并不可靠,因为即使使用“A...
    编程 发布于2024-12-21
  • 除了“if”语句之外:还有哪些地方可以在不进行强制转换的情况下使用具有显式“bool”转换的类型?
    除了“if”语句之外:还有哪些地方可以在不进行强制转换的情况下使用具有显式“bool”转换的类型?
    无需强制转换即可上下文转换为 bool您的类定义了对 bool 的显式转换,使您能够在条件语句中直接使用其实例“t”。然而,这种显式转换提出了一个问题:“t”在哪里可以在不进行强制转换的情况下用作 bool?上下文转换场景C 标准指定了四种值可以根据上下文转换为的主要场景bool:语句:if、whi...
    编程 发布于2024-12-21
  • 如何增加 Web 表单的最大 POST 数据大小?
    如何增加 Web 表单的最大 POST 数据大小?
    最大化后期数据处理以增强表单提交在 Web 开发中,经常会遇到需要处理大量数据(例如用户输入或文件上传)的情况。通过表单元素提交。处理大量发布数据对于确保网站的无缝运行至关重要。但是,可能存在限制最大帖子大小的限制,从而导致意外错误并阻碍数据提交。为了应对这一挑战,必须探索增加 Web 应用程序中最...
    编程 发布于2024-12-21
  • 如何在 C++ 中定义静态 const std::string 成员?
    如何在 C++ 中定义静态 const std::string 成员?
    定义 const std::string 类型的静态数据成员在 C 中,定义 std::string 类型的私有静态 const 成员在类内使用类内初始化,如下所示,不符合C标准:class A { private: static const string RECTANGLE = ...
    编程 发布于2024-12-21
  • 使用 Uvicorn 在 FastAPI 中发出并发 HTTP 请求时如何避免“ConnectionClosed”错误?
    使用 Uvicorn 在 FastAPI 中发出并发 HTTP 请求时如何避免“ConnectionClosed”错误?
    在 Uvicorn/FastAPI 中发出 HTTP 请求处理使用 FastAPI 和 Uvicorn 构建的 HTTP 端点时,通常会从外部 API 请求数据。但是,在处理多个并发请求时,可能会出现“can't handle event type ConnectionClosed when...
    编程 发布于2024-12-21
  • 如何修复 macOS 上 Django 中的“配置不正确:加载 MySQLdb 模块时出错”?
    如何修复 macOS 上 Django 中的“配置不正确:加载 MySQLdb 模块时出错”?
    MySQL配置不正确:相对路径的问题在Django中运行python manage.py runserver时,可能会遇到以下错误:ImproperlyConfigured: Error loading MySQLdb module: dlopen(/Library/Python/2.7/site-...
    编程 发布于2024-12-21
  • 如何使用非标准证书文件在Go Web服务器上建立HTTPS?
    如何使用非标准证书文件在Go Web服务器上建立HTTPS?
    如何使用非标准证书文件在 Go Web 服务器上建立 HTTPS提供的文档建议连接三个 .pem 文件。但是,如果您没有这些文件,以下是如何使用您拥有的证书文件设置 HTTPS:组合中间证书:虽然 Go 通常需要一个串联的证书文件,其他平台仅存储根证书。为了确保兼容性,请连接中间证书:cat web...
    编程 发布于2024-12-21
  • 如何可靠地处理带有子元素的绝对定位 div 上的鼠标移出事件?
    如何可靠地处理带有子元素的绝对定位 div 上的鼠标移出事件?
    在没有 jQuery 的情况下处理带有子元素的绝对 Div 中的 Mouseout 事件处理绝对定位的 div 时,处理 mouseout 事件可能具有挑战性。默认情况下,如果鼠标悬停在父 div 内的子元素上,则在鼠标退出外部 div 之前,mouseout 事件会提前触发。要解决此问题,请考虑使...
    编程 发布于2024-12-21
  • PHP 的 `==` 和 `===` 运算符有什么区别?
    PHP 的 `==` 和 `===` 运算符有什么区别?
    PHP Double (==) 和 Triple (===) 相等比较有何不同?在 PHP 中比较值时,两个可以使用不同的运算符:松散相等 (==) 运算符和严格相同 (===) 运算符。了解它们的细微差别对于确保可靠的比较至关重要。松散相等 (==) 比较松散相等运算符在比较值之前执行类型杂乱操作...
    编程 发布于2024-12-21

免责声明: 提供的所有资源部分来自互联网,如果有侵犯您的版权或其他权益,请说明详细缘由并提供版权或权益证明然后发到邮箱:[email protected] 我们会第一时间内为您处理。

Copyright© 2022 湘ICP备2022001581号-3