」工欲善其事,必先利其器。「—孔子《論語.錄靈公》
首頁 > 程式設計 > 探索用於 JavaScript 模組管理的 JSR

探索用於 JavaScript 模組管理的 JSR

發佈於2024-07-31
瀏覽:119

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]刪除
最新教學 更多>
  • 如何擴展 JavaScript 中的內建錯誤物件?
    如何擴展 JavaScript 中的內建錯誤物件?
    擴充 JavaScript 中的 Error要擴充 JavaScript 中的內建 Error 對象,您可以使用 extends 關鍵字定義 Error 的子類別。這允許您使用附加屬性或方法建立自訂錯誤。 在 ES6 中,您可以定義自訂錯誤類,如下所示:class MyError extends E...
    程式設計 發佈於2024-11-03
  • 將測試集中在網域上。 PHPUnit 範例
    將測試集中在網域上。 PHPUnit 範例
    介紹 很多時候,開發人員嘗試測試 100%(或幾乎 100%)的程式碼。顯然,這是每個團隊應該為他們的專案達到的目標,但從我的角度來看,只應該完全測試整個程式碼的一部分:您的網域。 域基本上是程式碼中定義項目實際功能的部分。例如,當您將實體持久保存到資料庫時,您的網域不負責將其持...
    程式設計 發佈於2024-11-03
  • 如何使用 SQL 搜尋列中的多個值?
    如何使用 SQL 搜尋列中的多個值?
    使用 SQL 在列中搜尋多個值建立搜尋機制時,通常需要在同一列中搜尋多個值場地。例如,假設您有一個搜尋字串,例如“Sony TV with FullHD support”,並且想要使用該字串查詢資料庫,將其分解為單字。 透過利用 IN 或 LIKE 運算符,您可以實現此功能。 使用 IN 運算子IN...
    程式設計 發佈於2024-11-03
  • 如何安全地從 Windows 登錄讀取值:逐步指南
    如何安全地從 Windows 登錄讀取值:逐步指南
    如何安全地從Windows 註冊表讀取值檢測登錄項目是否存在確定登錄項目是否存在: LONG lRes = RegOpenKeyExW(HKEY_LOCAL_MACHINE, L"SOFTWARE\\Perl", 0, KEY_READ, &hKey); if (lRes...
    程式設計 發佈於2024-11-03
  • Staat原始碼中的useBoundStoreWithEqualityFn有解釋。
    Staat原始碼中的useBoundStoreWithEqualityFn有解釋。
    在這篇文章中,我們將了解Zustand原始碼中useBoundStoreWithEqualityFn函數是如何使用的。 上述程式碼摘自https://github.com/pmndrs/zustand/blob/main/src/traditional.ts#L80 useBoundStoreWi...
    程式設計 發佈於2024-11-03
  • 如何使用 Go 安全地連接 SQL 查詢中的字串?
    如何使用 Go 安全地連接 SQL 查詢中的字串?
    在Go 中的SQL 查詢中連接字串雖然文字SQL 查詢提供了一種簡單的資料庫查詢方法,但了解將字串文字與值連接的正確方法至關重要以避免語法錯誤和類型不匹配。 提供的查詢語法:query := `SELECT column_name FROM table_name WHERE colu...
    程式設計 發佈於2024-11-03
  • 如何在 Python 中以程式設計方式從 Windows 剪貼簿檢索文字?
    如何在 Python 中以程式設計方式從 Windows 剪貼簿檢索文字?
    以程式設計方式存取Windows 剪貼簿以在Python 中進行文字擷取Windows 剪貼簿充當資料的臨時存儲,從而實現跨應用程式的無縫數據共享。本文探討如何使用 Python 從 Windows 剪貼簿檢索文字資料。 使用 win32clipboard 模組要從 Python 存取剪貼簿,我們可...
    程式設計 發佈於2024-11-03
  • 使用 MySQL 預存程序時如何存取 PHP 中的 OUT 參數?
    使用 MySQL 預存程序時如何存取 PHP 中的 OUT 參數?
    使用MySQL 預存程序存取PHP 中的OUT 參數使用MySQL 儲存程序存取PHP 中的OUT 參數使用PHP 在MySQL 中處理預存程序時,取得由於文件有限,「 OUT”參數可能是一個挑戰。然而,這個過程可以透過利用 mysqli PHP API 來實現。 使用mysqli$mysqli =...
    程式設計 發佈於2024-11-03
  • 在 Kotlin 中處理 null + null:會發生什麼事?
    在 Kotlin 中處理 null + null:會發生什麼事?
    在 Kotlin 中處理 null null:會發生什麼事? 在 Kotlin 中進行開發時,您一定會遇到涉及 null 值的場景。 Kotlin 的 null 安全方法眾所周知,但是當您嘗試新增 null null 時會發生什麼?讓我們來探討一下這個看似簡單卻發人深省的情況吧! ...
    程式設計 發佈於2024-11-03
  • Python 字串文字中「r」前綴的意思是什麼?
    Python 字串文字中「r」前綴的意思是什麼?
    揭示「r」前綴在字串文字中的作用在Python中創建字串文字時,你可能遇到過神秘的“r” ” 前綴。此前綴具有特定的含義,可能會影響字串的解釋,尤其是在處理正則表達式時。“r”前綴表示該字串應被視為「原始」字串。 &&&]在常規字串中,轉義序列如\ n 和\t 被解釋為表示特殊字符,例如換行符和製表...
    程式設計 發佈於2024-11-03
  • 如何解決舊版 Google Chrome 的 Selenium Python 中的「無法找到 Chrome 二進位」錯誤?
    如何解決舊版 Google Chrome 的 Selenium Python 中的「無法找到 Chrome 二進位」錯誤?
    在舊版Google Chrome 中無法使用Selenium Python 查找Chrome 二進位錯誤在舊版Google Chrome 中使用Python 中的Selenium 時,您可能會遇到以下錯誤:WebDriverException: unknown error: cannot find ...
    程式設計 發佈於2024-11-03
  • `.git-blame-ignore-revs` 忽略批量格式變更。
    `.git-blame-ignore-revs` 忽略批量格式變更。
    .git-blame-ignore-revs 是 2.23 版本中引入的一项 Git 功能,允许您忽略 git Blame 结果中的特定提交。这对于在不改变代码实际功能的情况下更改大量行的批量提交特别有用,例如格式更改、重命名或在代码库中应用编码标准。通过忽略这些非功能性更改,gitblame 可以...
    程式設計 發佈於2024-11-03
  • 掌握函數參數:JavaScript 中的少即是多
    掌握函數參數:JavaScript 中的少即是多
    嘿,開發者們! ?今天,讓我們深入探討編寫乾淨、可維護的 JavaScript 的關鍵方面:管理函數參數 太多參數的問題 你有遇過這樣的函數嗎? function createMenu(title, body, buttonText, cancellable, theme, fon...
    程式設計 發佈於2024-11-03
  • 如何使用 FastAPI WebSockets 維護 Jinja2 範本中的即時評論清單?
    如何使用 FastAPI WebSockets 維護 Jinja2 範本中的即時評論清單?
    使用FastAPI WebSockets 更新Jinja2 範本中的項目清單在評論系統中,維護最新的評論清單至關重要提供無縫維護的使用者體驗。當新增評論時,它應該反映在模板中,而不需要手動重新加載。 在Jinja2中,更新評論清單通常是透過API呼叫來實現的。然而,這種方法可能會引入延遲並損害使用者...
    程式設計 發佈於2024-11-03
  • 掌握 SQL 查詢:&#教師薪資格查詢&# 項目
    掌握 SQL 查詢:&#教師薪資格查詢&# 項目
    您是否希望提升 SQL 技能並學習如何有效管理 MySQL 資料庫? LabEx 提供的教師薪資格式查詢專案就是您的最佳選擇。這個綜合計畫將引導您完成在大學資料庫中查詢和格式化教職員工薪資的過程,為您提供必要的知識和技能,以在資料管理工作中脫穎而出。 介紹 在這個引人入勝的專案中,...
    程式設計 發佈於2024-11-03

免責聲明: 提供的所有資源部分來自互聯網,如果有侵犯您的版權或其他權益,請說明詳細緣由並提供版權或權益證明然後發到郵箱:[email protected] 我們會在第一時間內為您處理。

Copyright© 2022 湘ICP备2022001581号-3