copy (in case the original goes offline).
Examples of two npm modules I've successfully published and used using the above guides:
If you follow the structure of my modules mentioned above be sure to change the
main attribute in
Failure to do so will result in "cannot find package" messages when the module is required.
npm install . -g
To verify the local-global installation do a:
npm list -g --depth 0Alternatively (and to also allow some REPL-type testing), cd to some other directory, open a repl (node or nodejs) and require your package to test its newly added functionality.
… however, after the initial local-global installation you will invariably encounter bugs that you will have to fix (locally again). After each fix you should do (from the root of your project):
npm run build && npm install . -g
During these (local) iterations (that don't get published to the public npm repository) you don't need to update the version in package.json.
NB:To ensure that the package you installed locally-globally is
visible to a Node REPL ensure that the main property
is properly set to the location of the compiled (if you are
using Babel) sources. E.g. I had in my
"main": "mul.js" which didn't work until
I changed it to:
"main": "lib/mul.js". This was necessary as my
compiled code resided under lib/ as per the build line (again in package.json):
"build" : "babel src --out-dir lib --source-maps"
For the locally-globally test to succeed you need to ensure that your
$NODE_PATH environment variable points to the location of the local-globally installed modules.
E.g. in one case I had to add the following to my
NB3: I have encountered cases where, even though the module was locally installed in the global location, it was still not visible to Webpack and I had to do an additional npm link. See this SO question of mine.
At the end of a number of such iterations you are now able to publish
Before you do that however, remember to update the version
Once this is done do:
However, even if you do forget to update package.json npm will baulk with an informative message, so no worries there.
Afterwards, you are able to install your package from everywhere by name (rather than, e.g. having to point at a Github URL):
npm install <your-package-name>You may also have to do a:
npm update -g <your-package-name>… to ensure that your package has been updated in the global (local) repository (though if you've already installed it locally with
npm install . -gyou may not see any difference. At any rate you can use the following command to find the locally available version of your package:
npm ls -g | grep <your-package-name>
The interplay between the two ignore files:
Both files need to be present as different sets of files should be ignored by git and npm. For instance:
A typical erroneous case I encountered during local global testing was that the lib/ directory in the local global publishing location included only the index.js file but not an app.js it required. I assume the lib/index.js file was included because it is explicitly identified in package.json:
$ cat package.json | grep main "main": "lib/index.js",As a result, I had this situation:
$ ls /home/mperdikeas/.node_modules_global/lib/node_modules/filtered-datastore/lib/ total 12 drwxrwxr-x 2 mperdikeas mperdikeas 4096 Jun 13 12:08 ./ drwxrwxr-x 6 mperdikeas mperdikeas 4096 Jun 13 12:08 ../ -rw-rw-r-- 1 mperdikeas mperdikeas 113 Jun 13 12:08 index.js… whereas when I properly added a .npmignore file I got (after the next
npm install . -g) the following situation:
$ ls /home/mperdikeas/.node_modules_global/lib/node_modules/filtered-datastore/lib/ total 24 drwxrwxr-x 2 mperdikeas mperdikeas 4096 Jun 13 12:16 ./ drwxrwxr-x 5 mperdikeas mperdikeas 4096 Jun 13 12:16 ../ -rw-rw-r-- 1 mperdikeas mperdikeas 3739 Jun 13 12:15 app.js -rw-rw-r-- 1 mperdikeas mperdikeas 3551 Jun 13 12:15 app.js.map -rw-rw-r-- 1 mperdikeas mperdikeas 113 Jun 13 12:15 index.js -rw-rw-r-- 1 mperdikeas mperdikeas 229 Jun 13 12:15 index.js.map
Refer to my filtered datastore
module for correct