How to develop optimal JS modules

This time I will show you how to develop the optimal JS module, and what are the precautions for developing the optimal JS module. The following is a practical case, let's take a look.

Many people have published their own JavaScript modules on npm. In the process of using some modules, I often get the error "This module is very useful, but It would be better if you could xxx" thought. Therefore, this article will summarize how to make the module more useful from the perspective of module users.

Provide the entrance to the ES6 module

Both webpack and rollup support some static optimizations for ES6 modules (such as Tree Shaking and Scope Hoisting), they will first read the module field in package.json as the entrance to the ES6 module. If there is no module, they will read it. The main field serves as the entry point to the CommonJS module. The usual approach is: use ES6 syntax to write source code, and then use module packaging tools combined with syntax conversion tools to generate CommonJS modules and ES6 modules, so that both main and module fields can be provided.

Provide TypeScript type declaration files

If your users use TypeScript but your module does not provide a declaration file, they will have to add a piece of code to the project to avoid TypeScript compilation errors; in addition, this is not just user-friendly for TypeScript, because most codeeditor (Webstorm, VS Code, etc.) can recognize TypeScript's type declarations can provide more precise code hints and prompt users when they pass in the wrong number or type of parameters.

Best practice is to use TypeScript Write your module and type declarations will be automatically generated at compile time. In addition, you can also manually maintain a declaration file by referring to the documentation. You can add index.d.ts in your module root directory file, or declare in package.json that the typings field provides the location of the declaration file.

Let the module run in Node.js and the browser at the same time

You can determine whether the module is currently running in Node.js or a browser by detecting whether there is a global variable named window (such as !!typeof window), and then use different ways to implement your functionality.

This method is relatively common, but if the user uses a module packaging tool, doing so will cause Node.js The browser implementation will be included in the final output file. In response to this problem, the open source community proposed adding browser to package.json Field proposal, currently both webpack and rollup already support this field.

The browser field can be used in two ways:

Provide a file path to the browser field as the module entry when used on the browser side. However, it should be noted that the packaging tool will give priority to using the file path specified in the browser field as the module entry, so your module field will be ignored. This will As a result, the packaging tool will not optimize your code. Please refer to this question for details.

If you only want to replace some of the files, you can declare an object.

For example, suppose you have two files in your module: http.js and xhr.js. The first file uses http in Node.js module initiates the request, and another implements the same functionality using XMLHTTPRequest in the browser. In order to use the appropriate files, your module code should always require(‘./path/to/http.js’), and declare in package.json:

{
 "browser": {
  "./path/to/http.js": "./path/to/xhr.js"
 }
}

In this way, when your module is used in the packaging tool, the packaging tool will only include the code of xhr.js in the final output file.

Arm your project with various services

Most JavaScript projects are open source, and the open source community also provides many free services for open source projects, which can provide more powerful help to your project. Here are a few of the more commonly used ones.

The most commonly used service in a project is continuous integration. The continuous integration service can put tasks such as testing, code style detection, and packaging on the server, and run them automatically when you submit the code. Commonly used ones include Travis CI, CircleCI and AppVeyor. Travis CI is free for open source projects and is available on Linux and OS X Running environment; CircleCI is free for both open source and private projects, but has a 1500-minute runtime limit per month; AppVeyor provides Windows The operating environment is also free for open source projects.

After running your tests, you can also upload your test coverage to Coveralls. This service allows you to browse the test coverage of your code online.

If you want your modules to be fully tested under various versions of various browsers and platforms, you can also use Sauce Labs and BrowserStack. They are both free for open source projects, but you need to send an email to apply.

Finally, Shields IO provides a variety of icons that can provide a lot of additional information about your project, including but not limited to npm version number, download volume, test passing status, test coverage, file size, whether dependencies are expired, etc.

I believe you have mastered the method after reading the case in this article. For more exciting information, please pay attention to other related articles on the php Chinese website!

Recommended reading:

Webpack express multi-page site development and implementation steps

Webpack framework usage summary

The above is the detailed content of How to develop optimal JS modules. For more information, please follow other related articles on the PHP Chinese website!