How to Develop Better JavaScript Modules

Many people have published their own developed JavaScript modules on npm, and during the use of some modules, I often have the idea that 'This module is very useful, but it would be better if it could do xxx'. Therefore, this article will summarize from the perspective of a module user, how to make modules more user-friendly.

Provide ES6 The entry point of the module

Both webpack and rollup support ES6 Static optimization (such as Tree Shaking and Scope Hoisting) for modules, which will all prioritize reading the module field in package.json as ES6 The entry point of the module, if there is no module, the main field will be read as the entry point of the CommonJS module. The usual practice is to use ES6 Write source code in syntax, then use module packaging tools combined with syntax conversion tools to generate CommonJS modules and ES6 modules, so that both 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 declaration files, they will have to add a piece of code to their project to avoid TypeScript compilation errors; in addition, this approach is not only user-friendly for TypeScript users, because most code editors (Webstorm, VS Code, etc.) can recognize TypeScript type declarations, which can provide more accurate code hints and give hints when the user enters the wrong number of parameters or types.

The best practice is to write your module in TypeScript, which will automatically generate type declarations during compilation. In addition, you can also refer to the documentation to manually maintain a declaration file. You can add an index.d.ts file in the root directory of your module, or declare the location of the declaration file in the typings field of package.json.

Running modules in both Node.js and the browser

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

This method is quite common, but if the user uses a module packaging tool, this will result in both Node.js and browser implementations being included in the final output file. In response to this issue, the open source community proposed adding a browser field in package.json, and currently, webpack and rollup both support this field.

There are two ways to use the browser field:

Provide a file path for the browser field as the module entry point when used on the browser side, but note that the packaging tool will prioritize the file path specified in the browser field as the module entry point, so your module field will be ignored, which will cause the packaging tool not to optimize your code. For more details, please refer to this issue.

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

For example, suppose your module contains two files: http.js and xhr.js. The first file initiates requests using the http module in Node.js, and the other implements the same function using the XMLHTTPRequest in the browser. To use the appropriate file, your module code should always require(‘./path/to/declare (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 a packaging tool, the packaging tool will only include the code of xhr.js in the final output file.

Arming 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 assistance to your project. Here are several commonly used ones listed.

The most commonly used service for a project is continuous integration. Continuous integration services can place tasks such as testing, code style checking, and packaging on the server and automatically run them when you submit code. Common ones include Travis CI, CircleCI, and AppVeyor. Travis CI is free for open-source projects, providing Linux and OS X runtime environments; CircleCI is free for both open-source and private projects, but there is a 1500 minutes of runtime limit; AppVeyor provides a Windows runtime environment, which is also free for open-source projects.

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

If you want to ensure that your module is fully tested on various browsers and platforms across different versions, you can also use Sauce Labs and BrowserStack. They are free for open-source projects, but you need to send an email to apply.

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

That's all for the tutorial on how to develop good JavaScript modules that we share with you. If you have any questions, you can discuss them in the comment area below. Thank you for your support of the Yell Tutorial.

Statement: The content of this article is from the Internet, and the copyright belongs to the original author. The content is contributed and uploaded by Internet users spontaneously. This website does not own the copyright, has not been manually edited, and does not assume any relevant legal liability. If you find any content suspected of copyright infringement, please send an email to: notice#oldtoolbag.com (when sending an email, please replace # with @ to report, and provide relevant evidence. Once verified, this site will immediately delete the infringing content.)