Code Journey - Old Dog / New Tricks: One Approach to Multiple Projects (Node.js/Vue.js/React.js) - NPM Scope

kshoultz (25)in #nodejs • 6 years ago (edited)

TLDR

So I recently found an approach that felt correct for one of my concerns, and I want to share it. How do I share node.js code from my node-library project? And how do I not share it with the world? My answer was found using the npmjs.com repository. Hopefully, I can save someone some time.

Keywords to skip to:

Publishing the private package
Using your privately published package in your dependent project
Deployment Tip: NPM_TOKEN
Developer Tip: npm link

Publishing the private package:

You will need to create an account with npmjs.com
You will need to sign up for the private packages upgrade.
You will need to modify the package name of your project to use the private scope that you created in the upgrade process. ("name": "@new-scope/your-library-project")
You can publish your package to the npmjs.com by typing "npm publish" from your project command line.
You can check your published package on the npmjs.com website under your profile (this will verify that your good to go from npmjs.com perspective).

Using your privately published package in your dependent project:

You must now log into your npm command line. Type "npm login" and provide your username, password, and public email.
In your dependent project, install the privately published package by typing: "npm install @your-new-scope/your-dependent-project".
You should see the package install in the console window.
You should now be able to use your privately published package.
Require the code as you would, using this format: const mylibrary = require("@my-scope/my-library-project");

Deployment Tip: NPM_TOKEN

If you are deploying to a server, the server will need to authenticate against your private package. Without this step, your server deployment build will break.

~~1. Your project needs the file ".npmrc" in its root.~~
1. In that file, you need the token reference: //registry.npmjs.org/:_authToken={NPM_TOKEN}
1. I recommend creating a read-only token for your server. That way it doesn't change every time your user token changes. In your scoped package directory, type npm token create --read-only
~~1. You should see a full token value. RECORD THIS! This is the only time you will see it.~~
~~1. You will need to set up an environment variable on your server called NPM_TOKEN with that value of your newly created read-only token.~~
1. I don't know your server deployment, so I won't give you those step-by-step details. But if you are this far, you should be able to find it in your server documentation. (Note: I heard that this MIGHT be a Heroku only thing. Keep that in your back pocket)

UPDATE: I was having issues with this step until I found this article: http://particlebanana.com/2016/06/09/using-private-npm-modules-on-heroku/ Essentially, putting the .npmrc file in your project has two problems. 1) it's in your way when you want to download to your machine. 2) I couldn't get it to work on Heroku anyway. So follow the instructions in the link.

Developer Tip: npm link

The above is great when it's all ready to go. But if you need to test and work on the library itself, it is way too slow. You want to be able to make as many changes to the library as you want locally. You want to see the changes immediately. For this you can use npm link. Here's how I use it:

Navigate to your shared package project.
Type "npm link" to set it up as a shared directory.
Navigate to your dependent project.
Type "npm link your-library-project" and it will set up the link. Your project is ready to include the library.
I have two lines in my code where I import the library package, so I can easily swap in development by commenting one.
const mylibrary = require("@my-scope/my-library-project"); // This is your npm download package line.
const mylibrary = require("my-library-project"); // This is the line you can use to take advantage of the npm link.

For reference, these were my ideal goals for my multiple project structure:

I want my Vue.js (or React.js) project to be its own clean project called "my-vuejs-client". I COULD build this and place it on any "server" project (or serverless).
I want my Node.js server project to be in its own clean project called "my-node-server". It has a public directory that I could build "my-vuejs-client" into. It typically has express restful services.
I want a "library" node.js project that shares code with different node server projects I make. Possibly called "node-library-project". This would hold code that I don't want to copy and paste into every project.
I'll eventually have a client project for shared vue.js components and stuff, but that can be for another day to discuss. I haven't dug too deeply here.

This was the article I originally posted, in all of its n00b1sh glory:
https://steemit.com/nodejs/@kshoultz/code-journey-old-dog-new-tricks-stop-spinning-your-wheels-and-ask-for-help-architect-multiple-js-projects

I didn't want to use NPM to publish my library code. I didn't feel it was useful for public consumption, as it was my implementation of business logic type stuff. What I didn't know is that you could publish private packages. I still didn't think I wanted to publish my code in two places, but I guess that's the nature of the beast. The downside is, that it is not free. I get it. I'm okay with the business model. But I have found that there are a lot of hidden costs within this open-source approach. $7 here for npm, $7 there for github, $5 for heroku. It would just be nice to knnow these things up front so I'm not suprised.

So here is a small rundown of cost for website overhead (Based on my choices):

$7/month: GitHub.com (Developer Plan – Unlimited private repositories)
$7/month: NPMjs.com (Private Packages upgrade)
$5/month: Heroku.com (To start getting fancy with a server. This is basic so far, but it will most certainly grow based on what I build)
$11/year: NameCheap.com (Domain name hosting)

Is it the ideal answer?

I don't think so. For now, it will cost me $7 a month. But it is one correct and working solution. I will continue my journey and share what I find. My next goals are to find the best way to structure server-side and client side projects in my workspace.