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

探索用於 JavaScript 模組管理的 JSR

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

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]刪除
最新教學 更多>
  • 如何在 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,與未解析的外部符號有關。 解決方案要修正此問題,請遵循特定準則來確保程式碼庫的正確組織: 模組化程式碼: 每個C模...
    程式設計 發佈於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'] 是否存在的傳統方法並不可靠,因為即使使用“Apach...
    程式設計 發佈於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 = &q...
    程式設計 發佈於2024-12-21
  • 使用 Uvicorn 在 FastAPI 中發出並發 HTTP 請求時如何避免「ConnectionClosed」錯誤?
    使用 Uvicorn 在 FastAPI 中發出並發 HTTP 請求時如何避免「ConnectionClosed」錯誤?
    在Uvicorn/FastAPI 中發出HTTP 請求處理使用FastAPI 和Uvicorn 建構的HTTP 端點時,通常會從外部要求資料。但是,在處理多個並發請求時,可能會出現「can't handle event type ConnectionClosed when role=SERV...
    程式設計 發佈於2024-12-21
  • 如何使用非標準憑證檔案在Go Web伺服器上建立HTTPS?
    如何使用非標準憑證檔案在Go Web伺服器上建立HTTPS?
    如何使用非標準憑證檔案在 Go Web 伺服器上建立 HTTPS提供的文件建議連接三個 .pem 檔案。但是,如果您沒有這些文件,以下是如何使用您擁有的證書文件設定HTTPS:組合中間證書:雖然Go 通常需要一個串聯的證書文件,其他平台僅儲存根憑證。為了確保相容性,請連接中間憑證:cat websi...
    程式設計 發佈於2024-12-21
  • 如何可靠地處理帶有子元素的絕對定位 div 上的滑鼠移出事件?
    如何可靠地處理帶有子元素的絕對定位 div 上的滑鼠移出事件?
    在沒有jQuery 的情況下處理帶有子元素的絕對Div 中的Mouseout 事件處理絕對定位的div 時,處理mouseout 事件可能具有挑戰性。預設情況下,如果滑鼠懸停在父 div 內的子元素上,則在滑鼠退出外部 div 之前,mouseout 事件會提前觸發。 要解決此問題,請考慮使用 on...
    程式設計 發佈於2024-12-21
  • PHP 的 `==` 和 `===` 運算子有什麼不同?
    PHP 的 `==` 和 `===` 運算子有什麼不同?
    PHP Double (==) 和 Triple (===) 相等比較有何不同? 在 PHP 中比較值時,兩個可以使用不同的運算子:鬆散相等 (==) 運算子和嚴格相同 (===) 運算子。了解它們的細微差別對於確保可靠的比較至關重要。 鬆散相等 (==) 比較鬆散相等運算子在比較值之前執行型別雜亂...
    程式設計 發佈於2024-12-21
  • 如何在 JavaScript 中對字串執行數學運算?
    如何在 JavaScript 中對字串執行數學運算?
    將字串轉換為數字進行數學運算儘管包含數字字符,但字串不能直接作為數字進行操作。要執行算術運算,必須先將它們轉換為數字形式。 考慮給出的例子:var num1 = '20', num2 = '30.5';直接添加這些字串會導致串聯:num1 num2; // '2030.5'要強制將它們視...
    程式設計 發佈於2024-12-21
  • 儘管程式碼有效,為什麼 POST 請求無法擷取 PHP 中的輸入?
    儘管程式碼有效,為什麼 POST 請求無法擷取 PHP 中的輸入?
    解決PHP 中的POST 請求故障在提供的程式碼片段中:action=''而非:action="<?php echo $_SERVER['PHP_SELF'];?>";?>"檢查$_POST陣列:表單提交後使用 var_dump 檢查 $_POST 陣列的內...
    程式設計 發佈於2024-12-21
  • 為什麼我的 Div 重疊?了解並解決保證金崩潰問題
    為什麼我的 Div 重疊?了解並解決保證金崩潰問題
    邊距折疊:理解並解決Div 佈局中的重疊設計具有多個div 元素的佈局時,理解邊距的概念至關重要折疊以避免不必要的重疊邊距。邊距折疊是一種 CSS 行為,當相鄰元素的邊距合併在一起時會發生,有效地增加了它們之間的總邊距空間。 邊距折疊的原因在您的具體情況,重疊邊距可能是由於以下CSS 規則的組合造成...
    程式設計 發佈於2024-12-21
  • 第一個 PHP 8.3 候選版本現已可測試
    第一個 PHP 8.3 候選版本現已可測試
    即將推出的 PHP 版本的第一個候選版本 PHP 8.3 現已可供測試。 第一個普遍可用的PHP 版本計劃於今年11 月23 日發布,PHP 8.3 的第一個候選版本是一個重要的預發布里程碑,因為它表明了PHP 8.3 的所有更改現在已經實現,只剩下完善和錯誤修復了。 在 11 月 23 日 ...
    程式設計 發佈於2024-12-21

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

Copyright© 2022 湘ICP备2022001581号-3