NodeJS package.json dependency from github - node.js

I have a nodejs project, and a dependency:
https://github.com/MrRio/jsPDF
Usually i used package.json for manage my dependencies, but jsPDF isnt in npm, can i download it from github directly in package.json?

You sure can.
You can specify the repository as username/repo or use a full URL such as
git://github.com/user/project.git
So in your case it'd be
"dependencies": {
"jsPDF": "MrRio/jsPDF"
}
Also jsPDF is a client-side dependency. Meaning it won't work in Node.js and will only work in the browser, which is why it isn't in NPM, because it's not a Node.js module.

Related

How to distribute dependencies in package.json?

So I'm building a Front End application based on React. There'll be different packages serving as libraries and exporting components. These components will then be imported into the main package and routed according to need.
Now for the package(s) serving as libraries; I'm trying to understand how to distribute the dependencies between dependencies, devDependencies, and peerDependencies in the package.json file.
Should I be putting everything in dev and peer? Or do things like lodash / babel etc. need to be put in dependencies? Any such best practices; or list of dependencies would be helpful
About dependencies and devDependencies
Dependencies
"dependencies": Packages required by your application in production.
In dependencies you put everything that is imported in your application or needed in some way in the final application, e.g: react, axios etc.
devDependencies
"devDependencies": Packages that are only needed for local development and testing.
In devDependencies you put only things that are used to build your application, eg. webpack, eslint etc.
peerDependencies
You can read about peerDependencies here
You won't use them unless your project is a library.
Questions:
Should I be putting everything in dev and peer?
No, it's safer to put everything in dependencies if you don't know where to put it.
Or do things like lodash / babel etc. need to be put in dependencies?
No, lodash should be in dependencies, because, you are using it in your website. babel on the other hand is used only in built time, so it should be in devDependencies.

Overwriting node dependencies with github forked repo: npm shrinkwrap...?

I am building an app with Angular 4 cli, using the Dragula drag-and-drop stystem ng2-dragula. I want to update to this particular forked repo which provides some specific augmentation.
But I am struggling to install this with node. I can't simply run
npm install git://github.com/nguyenj/dragula.git
I think because in the ng2-dragula package.json, the dependency is specified as
"dependencies": {
"dragula": "^3.7.2"
},
I have tried to address this using npm-shrinkwrap, using the solution posted here (See section The Real Solution)
But it isn't working; Even if I manually change the dependencies section of the ng2-dragula package.json, running npm install just installs the original dragula, NOT the version I want from https://github.com/nguyenj/dragula
Why? How can I solve this?
Actually, this was something quite simple- no need to be overwriting anything- I just needed to specify the branch of the forked repo:
npm install git://github.com/nguyenj/dragula.git#feature/axis

Installing React in Meteor: Atmosphere or NPM

I have been installing React into Meteor projects using
npm install --save react react-dom
What is the difference between doing that and using a package from Atmosphere:
meteor add reactjs:react
It's more like a consistency assumption rather a real deal.
You may install react via bower , NPM , Atmosphere or even by cloning the repository.
In my projects, I had clarified dependency management as:
Use NPM for backend dependencies ( using Node.js ) or frontend dependencies that require a building / piping / bundling system like Babel, Webpack or Gulp.
Use Bower for "presentation" dependencies like Bootstrap, jQuery or prebuilt modules used as is.
Use any additional package management tool for any further dependency injection.
TL;DR
There are no differences between the two approaches ( although Atmosphere is not mentioned as a proper way to install / build React into the official docs)
If you prefer to keep React rendered in the browser use NPM or Bower. If you need to use React mapped into Meteor backend's code as an isomorphic app you may use Atmosphere as it is semantically used as a dependency.

Side-effects of declaring node inbuilt packages explicitly on package.json

I just tried putting the followings on my package.json deps list:
"http": "*",
"path": "*",
"fs": "*"
I ran the npm install and found that NPM downloaded these dependencies. Now I am curious to know
Are these downloads in the node_modules same as the packages originally inbuilt with node.js?
How does the require module in the node treat these modules i.e. will it return the node.js inbuilt implementation or the implementation present on the node_modules folder on the root directory.
Is my application going to behave differently because of this?
These packages are standart libraries and there is no need to install them under npm. Just:
var http = require('http');
All of them can be founded in API Docs
They download latest version that matches your npm & node versions.
Require will choose files from node_modules/
If backwards will be broken, than behaviors can differs, but node.js try to avoid change standard lib API.

Bower modules cache on heroku

I 've been using bower to install client-side dependencies, e.g. jquery and purecss, to my Node.js project. I add the following to my package.json and everything works like a charm - downloading the bower modules at deploy time.
"scripts": {
"postinstall": "bower install"
}
I was wondering though if it's possible to cache the modules, similar to how node-modules work, so I don't have to download them every-time I deploy my code. Any ideas how to do that?
It seems that there is no option to do this in the current nodejs buildpack.
There is a discussion about solving this here: https://github.com/heroku/heroku-buildpack-nodejs/pull/192/files
Heroku support custom cache directoies:
https://devcenter.heroku.com/articles/nodejs-support#cache-behavior

Resources