How to make js modules more useful

Many people have used JavaScript modules shared on npm, but sometimes the JavaScript modules they use would be better if they were easier to use. Therefore, this article will summarize from the perspective of module users how to make the module more useful. be more useful.

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 take priority. Read the module field in package.json as the entry of the ES6 module. If there is no module, the main field will be read as the entry 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 tips 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 judge by detecting whether there is a global variable named window (for example !!typeof window ) Whether the module is currently running in Node.js or the browser, 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 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 put forward a proposal to add the browser field in 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 there are 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 you When the 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. It can provide more powerful help for your project. Here are a few commonly used ones.

The most commonly used service in a project is continuous integration. Continuous integration services 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 provides Linux and OS

After running the test, 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 various 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.

Although most of the above suggestions are icing on the cake, they will make your module more user-friendly. I hope the above suggestions can give you some help when you develop your own module.

The above content is about how to make the js module more usable. I hope it can help everyone.

Related recommendations:

Detailed explanation of JavaScript modular programming

Detailed explanation of JavaScript modular programming

Detailed explanation of JavaScript modular development

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