Develop Reference

How to use external JS library methods in my Node.JS project if this library does not exist in NPM

I have a problem which can be easily solved by importing an external JS library into Node.js. However, this library does not exist in NPM.
I found out an old solution on StackOverflow which seems to fix the problem. However, it looks wierd.
Is there a more convenient solution in 2k20 to use external JS library methods into my Node.js code?

If your library have a package.json: You can install the package directly from the git repository, for example npm install https://github.com/vendor-creator/vendor-package. NOTE that for this method to work, in cases where the module has to be built, the git repository should contain a dist/ folder containing the built code or have in its package.json, a prepare step responsible for building the package upon installation.
If your library does not have a package.json and is simply a vanilla JavaScript file like the Lodash JavaScript file, I would advise just like in the post you linked, to create a vendor.js file (.min if the script is minified), copy and paste the content of the file and require it. Be aware that some libraries using CDN and not NPM, are designed for browser environment and may lack CommonJS support preventing you from using require. In that case you'll have to modify the library source code.
If it's a small library, there is no need to create an advanced build system. If the library is stable, just copy and paste it and you'll be fine. When in doubt always follow the K.I.S.S principle.

How to quickfix and build a bug in an NPM package, so it's available to the build server?

Maybe this question is a bit off the rules. I'm using and npm package, which built in type definitions for TypeScript. Unfortunately there is a bug in the definitions, which I can easily fix.
I want to make this new version of the package available to my build server. First I thought I can just fork the repository on Github and add this repository as the source in my package.json, but then I realized that this package needs to be built.
So my question is, where should I go from here? Of course I've sent a pull request, but what can I do until this is merged and released? Should I clone the package and publish it by myself?

I just forked the repo and build it with my fix included.
Then i used my github-fork in the package json.
(you can use github links with branch or tag annotations)
As soon as the merge was made i switched back to the original package.

I had quite similar problem with buggy type definitions. The steps to fix an npm package and then use are:
fork the package
create a new fix branch,
fix the bug, push to your forked repo,
point to the repo in your package.json,
create a pull request to help package maintainers 💪
You can find more details here on my blog: https://www.kozubek.dev/2019/02/23/fixing-npm-package.html
Hope this helps!

Publish Aurelia component on NPM?

We have built a small-ish application using Aurelia, and would like to be able to integrate the app into a larger codebase. For example, it may be desirable to publish the Aurelia app on NPM, so other projects could integrate our code.
How can we build/publish the Aurelia app, so that it can be instantiated in a larger JavaScript application?

Typically, you wouldn't publish an entire Aurelia application to NPM, rather you would push plugins to NPM.
The simplest way to learn how to do this is to follow the example of the various Aurelia repos. We build the code in to multiple formats, but the most important are AMD and CommonJS (which is more important for your company is dependent on what tooling your company is using). Once you've built the code, the next step is to make sure your package.json file is set up correctly. It's best to copy the example of what we're doing in our own repos.
I would start by looking at either the dialog plugin or the templating-resources plugin. Both of these show good examples of how to publish your Aurelia plugin to NPM, whether it is a public or private npm feed.
https://github.com/aurelia/dialog/blob/master/package.json
https://github.com/aurelia/templating-resources/blob/master/package.json
Both of these plugins are set up to support Webpack, JSPM/SystemJS, and the Aurelia CLI out of the box.

I totally agree with #Ashley in not publishing larger applications to the global NPM registry. The big advantage of it is the simplicity of all that small packages which can be used to build large applications.
If you feel you got some reusable code, put in an own package and publish it.
Anyway, to give you an answer which does not require you to publish your complete app: you can include a complete repository (which is probobly what you are lookig for) in a different application via NPM.
npm install git://github.com/somegit/hubrepo.git
Or directly via the package.json:
"dependencies": {
"private-repo": "git+ssh://git#github.com:somegit/hubrepo.git#v1.0.0",
}
You can also do something similiar e.g. using JSPM. This would be simply:
jspm install your-app=github:OrgOrUser/your-app#your-branch
If you are facing long relative paths in your imports now, depending on your tooling, you may be interested in something like e.g. Resolving require paths with webpack which shows how to alias relative paths.
Sources/Links:
How to install a private NPM module without my own registry?
npm install private github repositories by dependency in package.json

how to use a fork of a meteor package when the original package is a dependency

Context
I'm using the aldeed:autoform package and found a couple bugs & filed PR for it(https://github.com/aldeed/meteor-autoform).
Aldeed being the only maintainer of a lot of popular packages ends up being the bottleneck for merging PR & following up with issues.
My solution was to fork his project & published my fork on atmosphere.
Naively, i just removed his package meteor remove aldeed:autoform and tried to add mine: meteor add metakungfu:autoform
When i load my app, i get the following error:
Package['aldeed:autoform'] returns the expected object, even though i removed the package.
For sake of completeness, i do use a bunch of other packages that depends on aldeed:autoform and my guess is that this is the reason why aldeed:autoform package is still present.
Questions:
What's the right way to use a fork of a package, when that package is dependency of other packages?
Is this the right way to solve my problem?

I've end up using mgp to manage the packages.
In order to solve my problem, i had to do two things:
First, add a git-packages.json in the root of your project that looks like this:
➜ cat git-packages.json
{
"aldeed:autoform": {
"git": "git#github.com:gregory/meteor-autoform.git",
"branch": "dev"
}
}
This will work locally, but if you deploy to heroku, the buildpack will need to install mgp & install the dependencies.
I just opened a PR to fix this

Fork all the dependencies and make them point to your fork.

Instead of publishing your own version of aldeed:autoform onto Atmosphere, you should rather use it as a local package, keeping its name intact. Meteor will look first for your local packages, before trying to fetch from Atmosphere.
That way, all your other packages that depend on it will use your local version.
To do that, see: Why does Meteor's aldeed/meteor-tabular package get stuck processing and never render a result?
Reference: Meteor Guide > Build > Writing Atmosphere Packages > Overriding packages with a local version

What are npm, bower, gulp, Yeoman, and grunt good for?

I'm a backend developer, and slightly confused by npm, bower, gulp, grunt, and Yeoman. Whenever I ask someone what their purpose is, the answer tends to boil down to dependency manager - for all of them. Surely, we don't need four different tools that all do the same?
Can someone please explain what each of these is good for in as few sentences as possible - if possible just one per tool, using language a five year old (with development skills) could understand?
For example:
SVN stores, manages, and keeps track of changes to our source code
I have used maven, Jenkins, nexus and ant in the past; maybe you could compare the tools above to these?
Also feel free to add other front-end tools to the list.
Here is what I have found out so far - not sure it's correct, though:
bower dependency manager for front-end development/JS libraries, uses a flat dependency list
npm dependency manager for node.js server, can resolve transitive dependencies/dependency trees
grunt runs tasks, much like Jenkins, but locality on the command line
Yeoman provided scaffolding, i.e skeleton projects
gulp same as grunt, but written in js only
node.js server for js apps?
git decentralized SCM/VCS, counterpart to svn/cvs
Am I close? :)

You are close!
Welcome to JavaScript :)
Let me give you a short description and one feature that most developers spend some time with.
bower
Focuses on packages that are used in the browser. Each bower install <packagename> points to exactly one file to be included for (more can be downloaded). Due to the success of webpack, browserify and babel it's mostly obsolete as a first class dependency manager.
2018 Update: bower is mostly deprecated in favour of NPM
npm
Historically focuses on NodeJS code but has overthrown bower for browser modules. Don't let anyone fool you: NPM is huge. NPM also loads MANY files into your project and a fresh npm install is always a good reason to brew a new cup of coffee. NPM is easy to use but can break your app when changing environments due to the loose way of referencing versions and the arbitrariness of module publishing. Research Shrink Wrap and npm install --save-exact
2018 Update: NPM grew up! Lot's of improvements regarding safety and reproducibility have been implemented.
grunt
Facilitates task automation. Gulps older and somewhat more sluggish brother. The JavaScript community used to hang out with him in 2014 a lot. Grunt is already considered legacy in some places but there is still a great amount of really powerful automation to be found. Configuration can be a nightmare for larger use-cases. There is a grunt module for that though.
2018 Update: grunt is mostly obsolete. Easy to write webpack configurations have killed it.
gulp
Does the same thing as grunt but is faster.
npm run-script
You might not need task runners at all. NodeJS scripts are really easy to write so most use-cases allow for customizedtask-automation workflow. Run scripts from the context of your package.json file using npm run-script
webpack
Don't miss out on webpack. Especially if you feel lost on the many ways of writing JavaScript into coherent modular code. Webpack packages .js files into modules and does so splendidly. Webpack is highly extensible and offers a good development environment too: webpack-dev-server
Use in conjunction with babel for the best possible JavaScript experience to date.
Yeoman
Scaffolding. Extremly valuable for teams with different backgrounds as it provides a controllable common ground for your projects architecture. There even is a scaffolding for scaffolds.

So, Since you have a good idea what each is, I will give you a simple workflow.
I use yeoman to scaffold a basic skeleton.
I am using node as the runtime for my application. ie. run node appname
I use npm to install node modules for helping me write the application in node
I might need some component from bower like front-end libraries so use bower to fetch these.
Now to do some repetitive task I will use grunt or gulp to write some tasks. So everytime I want to repeat it, say minimify my js files I call grunt/gulp and make them do it. Difference you ask, Gulp is stream based while grunt is task based.
I do version control using git to keep track of changes

Gulp vs Grunt: Gulp provides more flexibility with task automation, Grunt comes built in with a lot of functionality as per the common development practices. There are two main differences between Grunt and Gulp:
Grunt focuses on configuration, while Gulp focuses on code
Grunt was built around a set of built-in, and commonly used tasks, while Gulp came around with the idea of enforcing nothing, but how community-developed micro-tasks should connect to each other Read here
NodeJS: It is a Non-blocking server-side scripting language. Which means operations won't block further execution until current operation finishes.
Git: As you mentioned it is an SCM tool, a widely used one. As per the GitHub docs it is different from other SCM tools as data is never deleted.
Git thinks of its data more like a set of snapshots of a mini filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot.
When you do actions in Git, nearly all of them only add data to the Git database. It is very difficult to get the system to do anything that is not undoable or to make it erase data in any way. As in any VCS, you can lose or mess up changes you haven’t committed yet; but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository.
Read More
Bower vs NPM : Bower and NPM are dependency managers but Bower modules are for front-end development. NPM is a huge collection of modules to be used with NodeJS backend. This SO answer covers it better

I added some details:
npm is a package manager for javascript, npm is nodejs's package ecosystem, but it can be used only for front-end projects.
grunt & gulp are useful to separate and automate tasks like minification, compilation, unit testing on command line, it's a way lighter solution than (for example) visual studio as the process is only a separated (and usually lightweight) command line/process.
Regarding the differences between gulp, grunt and bower there is already a ticket: What are the differences between Grunt, Gulp.js and Bower? Why & when to use them?
Nodejs is more a javascript runtime. Node.js allows the creation of web servers and networking tools using js and a collection of "modules" that handle various core functionality and other core functions. Source
This ticket resumes the differences between Git and Subversion: Why is Git better than Subversion?