When people say KOA2, what exactly are they saying? - node.js

Does anybody know what the relationship is between KOA and KoA2 in NPM?
Recently I was trying to use the KOA framework, and I was wondering which of the two code repositories in NPM, KOA and KoA2, What should I use? Or, when people say Koa2, they mean KOA 2.x and not Koa2 in npm?
If I want to use koa2 , what code repositories should I use ? koa or koa2 ?
Can anyone help me? Many thanks.

I just installed both of these side-by-side and diffed the installed code.
The NPM package koa2 at npmjs.com/package/koa2 is a clone, not a fork of the NPM package koa#2.0.0-alpha.7 at npmjs.com/package/koa — with some minor changes.
Stuff like this can pose security issues. The problem is that Evildoers™ publish NPM packages with names similar to a popular package. That package contains a trojan of some sort. People install it either by making a typo and not realizing it or by being confused about which is the real deal. So there's that.
In this case, I do not believe koa2 is malignant, but I would stay away from it.
Especially since Koa itself is currently (9 October 2020) at version 2.13.0.

Related

What is the purpose of installing frontend libraries on Node.js?

I understand that when we talk about the frontend we're talking about files being served to the browser of the person accessing my page. So, frontend javascript libraries are only javascript code that is being sent from my server to the browser.
So far everything is fine, what I don't understand is why npm has repositories for frontend libraries. Let's take this Leaflet example, I can install this library with npm using npm install leaflet -s. But what would be the purpose of doing that? I see that if I open Visual Studio Code and I declare this library with const leaflet = require('leaflet') then I can see its functions and documentation in a more clear way on the suggestions after typing leaflet.... I don't think that's the purpose of installing a library like Leaflet on Node.js though (since it works only on the frontend). What am I missing? Why would anyone install frontend only libraries on Node.js?
There are likely other reasons, but this is they reason I've done it and the reason I've seen other people do it: Many people use Node.js tooling to bundle/build webapps, so you might install your frontend dependencies, and then use rollup or webpack or browserify or TypeScript tooling or whatever to bundle it into a single .js file. Since you're likely already installing the tooling with npm, installing the libraries also with npm means you don't need some other tool to do it.
Additionally, people also use npm to install libraries for electron apps, cordova apps, React Native apps, etc. And these things can all use frontend libraries because they basically have a web view embedded. (To be honest, I'm not sure that's the case with React Native because I've never used it, but I assume it is.)
Since you mention Leaflet specifically, here is an example of someone using npm to install leaflet, and then using browserify to make it so that they can basically write Node.js code (including require('leaflet') and run it in the browser.

Which GraphQL package to use for the Node-express app

This question might seem opinion related but I am literally Puzzled about chosing NPM package for GraphQl
TO be frank, I am just Starting with GraphQL and I opened an article, That Article asked me to install express-graphQL. Blindly, I installed it.
Later on, I wasn't able to comprehend the article, I saw the next article
they were using apollo-server-express
Another Article, they were graphql-yoga
And then another article they are doing npm install apollo-server graphql
I am probably not pro like most of you who get things by reading description in npm module and while this question might be opinion related, and can someone help/guide me with graphQl package I should use.
I work with Node-Express

Is Node.js just used for dev-tooling on the front-end?

For my understanding, node.js is a javascript-engine which is running javascript-code without using a browser(window-global). You can use javascript on a server. But I saw now a lot of tutorials(react, angular, vue etc.). In every tutorial, I have to install something with npm. I can follow there are several dev-tools which I can use on my local machine to minimize my javscript-files or compile sass to css. But in the end, when I put my files on a webserver, I just have normal javascript-files, css-files etc. No node.js code in it, right?
My question is: React, angular, vue.js etc. are written in just normal javascript without node.js right? The reason why I use npm ist just to install every dependencies with one command, right?
A question more: Is there an any recommended order to learn all these frontend-development stuff? There are so much words I have to google it: angular.js, react, vue.js, vanilla.js, typescript, backbone.js, bower, grunt, webpack, yarn etc... I dont know where I start, so I look into few tutorials, but everytime I go through these tutorials, there is a new word(technology) I have to research.
I think you're getting your terminology a little muddled.
Node.js is a JavaScript runtime, built on Google Chrome’s V8 JavaScript engine. However, that is not to say that Node programs are executed in a browser. They aren’t. Rather, the creator of Node (Ryan Dahl) took the V8 engine and enhanced it with various features (such as a file system API and an HTTP library) to create a program we can use to execute JavaScript on our computers.
Node comes bundled with a package manager called npm which you can use to install packages (such as React and Angular) from the npm registry. These packages are indeed written in normal JavaScript (or a language that compiles to JavaScript, such as TypeScript).
The reason why I use npm is just to install every dependencies with one command, right?
Kinda. You can certainly use npm to install dependencies. However, it does a lot more that that. For example you can use npm scripts to carry out various build tasks, or you can create a package yourself and use npm to publish it to the registry.
A question more: Is there an any recommended order to learn all these frontend-development stuff?
As with everything, it depends. What are you trying to build? It's relatively pointless to learn about Node, npm, React and Angular if you are attempting to build a simple static website. If I were you, I'd define a clear goal and set about learning the technologies you'll need to reach that goal. Saying that, if you are doing anything with front-end development, learning about npm will be a good use of your time.
Here's an article by way of further reading that explains things a little more: https://www.sitepoint.com/an-introduction-to-node-js/

Is it still appropriate to use Bower to install Bootstrap instead of via NPM or NuGet?

I'm checking out tons of blogs like this one where it's explicitly stated that Bower is the preferred and recommended way install Bootstrap to my Core web app.
The recommended way to install client-side dependencies like Bootstrap in ASP.NET Core is via Bower (using bower.json, as shown above). The use of npm/NuGet are shown to demonstrate how easily Bootstrap can be added to other kinds of web applications, including earlier versions of ASP.NET.
Checking the date of the post seems to be settling as it's only a few weeks old but when I check e.g. the icon for dependencies and some other things, I'm getting the impression that the content might be actually a bit more aged than so.
I've been googlearching lately and I learned that there's a shift towards fewer-simpler-smaller approach. Especially I've discovered that NPM is often recommended for managing all the packages, including Bootstrap. (Now, just because someone says so, it doesn't automatically makes it true - we need to ask why would the one or the other approach be more advantageous.)
Question - what's the downside of using Bower to manage Bootstrap instead of installing it with NPM and omitting Bower all together?
I think that since bootstrap is a strictly front-end framework, the recommendation was to install it via bower. If you envision having server-side javascript in your project as well, then npm would be the recommended way to go now :)

Managing 2 npm packages that depend on eachother

I'm creating a npm package that only contains Sass, a small framework. I only want this package to contain the Sass (and a few grunt plugins) so that someone can install and build it without installing the documentation.
But in the case where someone wants to contribute to the project having only the Sass files isn't all that helpful. They would need the documentation (or an example) to view the changes.
So I would like 2 packages; 1 for the framework and 1 for the documentation.
The documentation package would require the framework, the framework package may or may not require the documentation. (You would never update the framework from documentation, only the documentation, but the framework is needed.)
Documentation required = wanting to contribute to framework
Documentation not required = just wanting to use the framework in a project
Basically, I want to give the person installing the framework the option of getting the docs or not.
Is this possible using dependencies vs devDependencies vs peerDependencies?
Thanks!
From above:
To someone who wants to contribute, wouldn't Github be a better option? They could just clone the repo instead of installing it from npm. You could use npmignore to ignore all the documentation from npm package, which will still remain on Github
Thanks #laggingreflex

Resources