The main field in package.json points to the Library entry and usually has three options:

1. Point to the source code entry file, such as SRC /index.js; 2. Point to the packaged development version, such as dist/library.js; 3. Point to the packaged release, such as dist/library.min.js.

There are two ways to refer to Library:

1. Directly referenced by script tag, suitable for simple pages; 2. References are required by require or import, which need to be packaged with the help of a packaging tool, suitable for complex pages.

This article looks at how the main field can be specified to accommodate various references.

Point to the source code entry file

The first approach points to the source entry, which only applies to require references. Since the point is source code, the library users need to use packaging tools such as Webpack to package the library themselves. This method has the following problems:

1. The webpack babel-loader configuration generally excludes node_modules, which means that the library will not be translated, which may cause the packaged code to include ES6 code, causing compatibility problems with earlier versions of browsers; 2. If library compilation requires some special Loader or Loader configuration, users should add these configurations to their own configuration, otherwise the compilation will fail. 3. Users’ packaging tools need to collect library dependencies, resulting in slow packaging compilation speed and affecting development experience.

In general, the first method requires the user to compile and package the library itself, which puts an additional burden on the user, so the source entry file is not suitable for the library entry. However, if the library is intended to run only on the Node side, SRC /index.js can be used as the library entry since the Node side does not need to compile and package the source code.

Point to the packaged development version

The main purpose of the development version is to facilitate debugging. File size is not a concern of the development version, because the development version is usually hosted on localhost and file size has little impact.

The development version mainly uses the following means to facilitate debugging and improve the development experience:

1. Do dependency collection and Babel translation in advance, that is, users do not need to do these two steps of library work, improve the efficiency of compilation and packaging; 2. Try to retain the format of the source code to ensure that the source code in the development version is basically readable; 3. Keep warning messages to warn developers of errors or unreasonable calls to the library.

Point 3 is achieved by adding something like the following to the library code:

if (process.env.NODE_ENV === 'development') {
  console.warn('Some useful warnings.')
}Copy the code

It seems that the DefinePlugin for Webpack will replace process.env.node_env with development, so the above code changes to:

if ('development' === 'development') {
  console.warn('Some useful warnings.')
}Copy the code

This means that the above condition is always true and the warning message will be displayed.

There was a recent argument with the iView developers about whether NODE_ENV should be set to development or production when building a development version of the library. They decided to set it to Production because it would reduce the size of the development version. If DefinePlugin replaces process.env.node_env with production, the previous example code would be:

if ('production' === 'development') {
  console.warn('Some useful warnings.')
}Copy the code

This means that when you use the library to develop your application, you will not see any warning messages, which makes it difficult to detect errors in advance. If (process.env.node_env === ‘development’) {} is not in my source code, so I can set it to production without any problems. Although your source code does not have such cues, your remote code may have them in devependencies, which will turn off the warning messages in the dependencies.

You might be wondering, “Doesn’t the size of the development package make my app a big package?” There’s nothing to worry about, because when the app is packaged as a live release, it goes through two additional steps:

1. Replace process.env.node_env with production using DefinePlugin to disable all warning messages; 2. Minify the application code with UglifyJsPlugin to reduce the application size. It also removes code like if (‘production’ === ‘development’) {} that will never be executed, further reducing the size of the application.

So, apply the development release at development time without worrying about the final application volume. However, if the development version of the library is referenced as a script tag at development time, it should be replaced with the release version of the response when it goes live.

Points to the packaged release

The release seeks to minimize the size, because network transfers are the slowest compared to the parsing time of the JS engine, so by reducing the size of the library, the network transfer time is reduced.

Reduce the file size of the release by setting process.env.node_env to production, and then minify the application code using UglifyJsPlugin and remove code that will never execute.

Is it appropriate to use the release version of the library as an entry file? Obviously not, because the release version is highly compressed and compact, the code is completely unreadable, and the application development phase is difficult to debug.

The release version is used to refer to the application as a script tag when it goes live.

conclusion

From the above analysis, it is reasonable to use the development version of the library as the entry point to the library, setting “main”: “dist/library.js”. As a library developer, you should also follow the convention of using development environment variables and keeping warning messages when building development versions of the library.