Reputation: 4698
I have done quite some search already. However, still having doubts about the 'main' parameter in the package.json of a Node project.
I know that the second question is quite weird. It is because I have hosted a Node.js application on OpenShift but the application consists of two main components. One being a REST API and one being a notification delivering service.
I am afraid that the notification delivering process would block the REST API if they were implemented as a single thread. However, they have to connect to the same MongoDB cartridge. Moreover, I would like to save one gear if both the components could be serving in the same gear if possible.
Any suggestions are welcome.
Upvotes: 272
Views: 223531
Reputation: 534
From the Node.js getting started documentation, it states;
An extra note: if the filename passed to require is actually a directory, it will first look for package.json in the directory and load the file referenced in the main property. Otherwise, it will look for an index.js.
Upvotes: 1
Reputation: 15908
As far as I know, it's the main entry point to your node package (library) for npm. It's needed if your npm project becomes a node package (library) which can be installed via npm by others.
Let's say you have a library with a build/, dist/, or lib/ folder. In this folder, you got the following compiled file for your library:
-lib/
--bundle.js
Then in your package.json, you tell npm how to access the library (node package):
{
"name": "my-library-name",
"main": "lib/bundle.js",
...
}
After installing the node package with npm to your JS project, you can import functionalities from your bundled bundle.js file:
import { add, subtract } from 'my-library-name';
This holds also true when using Code Splitting (e.g. Webpack) for your library. For instance, this webpack.config.js makes use of code splitting the project into multiple bundles instead of one.
module.exports = {
entry: {
main: './src/index.js',
add: './src/add.js',
subtract: './src/subtract.js',
},
output: {
path: `${__dirname}/lib`,
filename: '[name].js',
library: 'my-library-name',
libraryTarget: 'umd',
},
...
}
Still, you would define one main entry point to your library in your package.json:
{
"name": "my-library-name",
"main": "lib/main.js",
...
}
Then when using the library, you can import your files from your main entry point:
import { add, subtract } from 'my-library-name';
However, you can also bypass the main entry point from the package.json and import the code splitted bundles:
import add from 'my-library-name/lib/add';
import subtract from 'my-library-name/lib/subtract';
After all, the main property in your package.json only points to your main entry point file of your library.
Upvotes: 24
Reputation: 46401
If you have for instance in your package.json
file:
{
"name": "zig-zag",
"main": "lib/entry.js",
...
}
lib/entry.js
will be the main entry point to your package.
When calling
require('zig-zag');
in node, lib/entry.js
will be the actual file that is required.
Upvotes: 41
Reputation: 23795
One important function of the main
key is that it provides the path for your entry point. This is very helpful when working with nodemon
. If you work with nodemon
and you define the main
key in your package.json
as let say "main": "./src/server/app.js"
, then you can simply crank up the server with typing nodemon
in the CLI with root as pwd instead of nodemon ./src/server/app.js
.
Upvotes: 12
Reputation: 9035
From the npm documentation:
The main field is a module ID that is the primary entry point to your program. That is, if your package is named foo, and a user installs it, and then does require("foo"), then your main module's exports object will be returned.
This should be a module ID relative to the root of your package folder.
For most modules, it makes the most sense to have a main script and often not much else.
To put it short:
main
parameter in your package.json
if the entry point to your package differs from index.js
in its root folder. For example, people often put the entry point to lib/index.js
or lib/<packagename>.js
, in this case the corresponding script must be described as main
in package.json
.main
, simply because the entry point require('yourpackagename')
must be defined unambiguously.Upvotes: 234
Reputation: 1011
To answer your first question, the way you load a module is depending on the module entry point and the main parameter of the package.json.
Let's say you have the following file structure:
my-npm-module
|-- lib
| |-- module.js
|-- package.json
Without main parameter in the package.json, you have to load the module by giving the module entry point: require('my-npm-module/lib/module.js')
.
If you set the package.json main parameter as follows "main": "lib/module.js"
, you will be able to load the module this way: require('my-npm-module')
.
Upvotes: 76
Reputation: 1980
For OpenShift, you only get one PORT and IP pair to bind to (per application). It sounds like you should be able to serve both services from a single nodejs instance by adding internal routes for each service endpoint.
I have some info on how OpenShift uses your project's package.json to start your application here: https://www.openshift.com/blogs/run-your-nodejs-projects-on-openshift-in-two-simple-steps#package_json
Upvotes: -4