Examples to explain the development of better JavaScript modules

Many people have published their own JavaScript modules on npm. In the process of using some modules, I often have the idea of ​​"this module is very useful, but it would be better if it could use xxx". Therefore, this article will summarize how to make the module more useful from the perspective of module users. This article mainly shares how to develop better JavaScript modules and functions. I hope it can help everyone.

Provide the entrance to ES6 modules

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

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 only friendly to users who use TypeScript, because most code editors (Webstorm, VS Code, etc.) can recognize TypeScript type declarations, and they can provide more accurate code prompts accordingly. And a prompt will be given when the user passes in the wrong number or type of parameters.

The best way is to write your module in TypeScript, which will automatically generate type declarations at compile time. In addition, you can also manually maintain a declaration file by referring to the documentation. You can add an index.d.ts file in the root of your module, or provide the location of the declaration file in the typings field in package.json.

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 by detecting whether there is a global variable named window (such as !!typeof window) .js or in the browser, and then use different ways to implement your functions.

This method is relatively common, but if the user uses a module packaging tool, this will cause the implementation of Node.js and the browser to be included in the final output file. In response to this problem, the open source community has proposed adding the browser field to package.json. 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, but 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, which will cause the packaging tool not to 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 the http module in Node.js to initiate a request, and the other uses the http module in the browser. XMLHTTPRequest implements the same functionality. In order to use the appropriate file, you should always require('./path/to/http.js') in your module code and declare it 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 your project with For more powerful help, here are a few of the more commonly used ones.

The most commonly used service in a project is continuous integration. Continuous integration services can place testing, code style detection, packaging and other tasks 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 provides Linux and OS

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

If you want your module to be fully tested under various versions of browsers and platforms, you can also use Sauce Labs and BrowserStack. They are both free for open source projects, but they need to be published. Apply by email.

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 pass status, test coverage, file size, Whether the dependency is expired, etc.

Related recommendations:

Analysis of the loading method of JavaScript modules

Detailed explanation of javascript modular programming

JavaScript modular development library SeaJS

The above is the detailed content of Examples to explain the development of better JavaScript modules. For more information, please follow other related articles on the PHP Chinese website!