Npm links: sharing via git


#1

I have an issue understanding how we are supposed to use npm link in a team environment. As this is really an npm question I’ve asked it on StackOverflow

However I’m intrigued about how this applies to OS.js apps, as we use npm link. Apologies if this is a non-issue, I don’t “think” npm yet.

Seems to me that npm link module depends on the global npm directory, which any colleagues that take my projects from git will not have set up. What’s the process supposed to be for sharing projects?


#2

Yes, npm link uses the global directory, but you should use nvm to manage the node installation. That way the “global” directory is inside the developers home directory.

https://docs.npmjs.com/getting-started/fixing-npm-permissions

You don’t have to use npm to distribute your apps (npm has git support for example), but as of now development relies on npm link.

Ideally, applications and things like that should be kept in their own repositories. That way you just use the regular git workflow + npm link.

Example:

# First set up OS.js base
cd ~/Projects/osjs
git clone https://github.com/os-js/OS.js.git -b v3
cd OS.js
npm install

# Check out some application source
cd ~/Projects/osjs
git clone https://repo/osjs-application.git
cd osjs-application.git
npm link

# Link the package
cd ~/Projects/osjs
cd OS.js
npm link osjs-application
npm run package:discover

You can use tools like https://github.com/lerna/lerna to automate this process for you in a team environment.

My development setup basically looks like this:

manual.os-js.org/
www.os-js.org/
distro/
sources/
  osjs-ace-application/
  osjs-calculator-application/
  osjs-cli/
  osjs-client/
  osjs-common/
  osjs-database-auth/
  osjs-database-settings/
  osjs-dbus-provider/
  osjs-dialogs/
  osjs-draw-application/
  osjs-example-application/
  osjs-example-iframe-application/
  osjs-example-provider/
  osjs-example-react-application/
  osjs-filemanager-application/
  osjs-gapi-provider/
  osjs-gdrive-adapter/
  osjs-gnome-icons/
  osjs-gui/
  osjs-htmlviewer-application/
  osjs-json-config-cli/
  osjs-meta/
  osjs-musicplayer-application/
  osjs-pam-auth/
  osjs-panels/
  osjs-pdfreader-application/
  osjs-pm2-provider/
  osjs-preview-application/
  osjs-raspi-wifi-provider/
  osjs-server/
  osjs-sqlite-auth/
  osjs-standard-dark-theme/
  osjs-standard-theme/
  osjs-strophejs-application/
  osjs-textpad-application/
  osjs-webdav-adapter/
  osjs-widgets/
  osjs-xpra-application/
  osjs-xterm-application/

All of this said though, I’m going to add support in @osjs/cli so you don’t have to use the npm link feature (this is on the TODO already). The plan is to just add support for adding any path so npm run package:discover runs over them all, not only node_modules/.


#3

… speaking of this, I’ll publish that tomorrow :wink:


#4

I just published the new @osjs/cli module that supports custom discovery paths. It also allows for overriding node_module packages, so you don’t run into problems in that regard :blush:

Updated relevant articles:

So now you don’t have to use npm link at all. You can just set your src/cli/index.js file to be:

const path = require('path');
module.exports = {
  discover: [
    // OS.js/src/packages
    path.resolve(__dirname, '../packages')
  ],
};

And npm run package:discover sets it up for you :slight_smile:


#5

Thank you for that. Very impressed at the speed of response!

I’m currently having a hard time thinking of a case where npm link is a better choice than this beautifully simple approach.

One issue that other folk may hit, unless this is specific to my environment: When I first tried a discover, before adding a path, so discover was still the empty array [] I got this error:

[esbadm@r2-mq OS3.js]$ npm run package:discover

@osjs/osjs@3.0.0-alpha.27 package:discover /home/esbadm/projects/OS3.js

osjs-cli package:discover

:arrow_forward: package:discover Initialized timer…

[package:discover] › … awaiting Discovering packages

{ Error: EACCES: permission denied, scandir ‘/lost+found’


#6

When working with modules that are imported in the codebase via node_modules (ex. core OS.js libraries), linking is the only way to override these modules without touching any of the original paths. So there’s a few use-cases still :slight_smile:

Ops. Fixed that.


#7

I’ve also published another version that deals with duplicate packages better (custom discovery paths now always take prioritization) and a bit better shell output :slight_smile:


#8

Thanks, this all seems to work smoothly.