Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 3 years ago.
Improve this question
I'm trying to run two scripts concurrently, and I found this package concurrently that supposedly would help me. I did npm install concurrently --save and it's listed in my package.json. When I go to run it, however, it throws:
concurrently: command not found
I don't understand why it can't find it despite being installed. I've set up the commands as shown here, so I know it can't be that. I've checked earlier instances of this issue, but it appears to be outdated. Is there another way I can check if this works, or should I try something else?
Screenshot:
When you install using npm install without specifying the global flag -g, you are installing the module to your projects node_modules folder. If that module has any runnable binaries, they will be added to node_modules/.bin - so you should be able to run your local version of concurrently by running node_modules/.bin/concurrently (or from any folder in your project $(npm bin)/concurrently). I personally prefer using the project's local dependencies over installing global ones so I have the option to use a different version in another project.
If you put a script into the package.json "scripts" field it will reference these locally installed without having to specify the full path because npm run adds your projects node_modules/.bin to your path.
If you're having issues, I would start by checking the node_modules/.bin folder and verifying that the binary for your script actually exists.
This issue also comes up when there is a dash "-" in your folder name. i.e. (/developer/api-movies) or even (/developer-apps/apiMovies. Use camelCase throughOut rather than dashes.
Related
I have been following various blogs and videos on setting up and configuring eslint and prettier for vscode and development. But every article fails to explain why do we need to separately install eslint as an npm package and vs code extension?
what difference it will make if I install either of the ones?
why do we need to separately install eslint as npm package and vscode extension?
Short answer: you don't.
Long answer:
Installing ESLint/Prettier as extension, allows you to format/check your code inside the VSCode.
However, installing them also as dependencies brings extra benefits:
VSCode will use exact same package as installed. So you will not spot the situation when VSCode says OK, but your CI server says: NOT OK
You will get control over the versions, and can update whenever you want
You will be able to use different versions for different projects. This is especially important, when you can't migrate old project, but want to use the latest possibilities for the new one
You will be able to access Prettier/ESlint through the script block of the package.json, and be able to write custom commands with parameters exactly as you need
You will be able to pair them with Husky or NPM hooks to automatically verify/format the code
From my experience, if you can install something locally - install it as package dependency (except CLI like create-react-app or angular-cli that helps you start the app). This will make your life a bit predictable.
These programs can format your code (ESLint and Prettier) and detect specific syntax (ESLint).
When installed as an extension in your IDE (vscode for example), you can get:
squiggly lines in real time;
and format-on-save.
But someone who starts up your project on their own environment might not have these extensions installed (might not even have the same IDE) and thus might not get these.
When installed as npm packages (and included somewhere in the pipeline, either in the npm start, or in your continuous deployment, or...)
you won't get real time squiggly lines,
but you can still get auto-formatting (though not necessarily on save, depending on the configuration),
you can get blocking rules (meaning instead of just seeing errors / warnings, you can actually block the pipelines until the dev fixes said errors / warnings)
you can insure anyone who starts the project, from any IDE, gets the packages included
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
In my company there is an old angular (Not even sure what version) client that no one touched for at least 2 years and I got the "lucky" job of changing some feature in this client.
The confusing part starts when I noticed there are no package.json, package-lock.json and angular.json files in the project but the whole node modules directory and compiled js files are stored in the git repository.
The problem is that I have no idea of how to rebuild this project after I change the typescript files. In addition, I want to remove the node modules directory from the git repository and have package.json instead.
No one that originally worked on this project is still in the company (Not surprised after I seen this mess).
The backend is written in asp.net framework and contains .cshtml files so I suspect there is some relation between the client and the server
Can someone help me rescue this project?
Sounds like a bit of a nightmare! You can try these steps to start but I'm sure you will have issues. Persevere as I think you can do it! Once you get some errors to work from it will be easier. Good luck
Look in node_modules for #angular/ folder and find the angular
version (if there isn't one then its AngularJS).
Create a brand new project using angular-cli using the version you just found.
copy the contents of the app folder (at least) to the new project.
Search through imports to see which libraries are used and npm install them.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm developping a web page using Vue.js, without backend (for the moment).
I need tabs, so 've looked at vue-tabs-component.
But to install it I need to :
npm install vue-tabs-component --save
How will this library be served to users ? They won't have npm installed nor npm install vue vue-tabs-components while navigating.
I'm developping only the frontend, therefore I don't need npm and I developp from several computers, several haven't npm.
Is there a way to use library only with <script src=...> ?
I took vue-tabs-component as example but my question is a general one: why have I to install frontend if it's gonna be served to client without them installing it ?
The word 'install' might cause some confusion for you here. npm install some-front-end-library downloads the files of our imaginary some-front-end-library package (e.g. a vue component).
After 'installing' (downloading the package), you reference to these files in your Vue project. E.g.
import somefrontendlibrary from 'some-front-end-library'
Vue.use(somefrontendlibrary);
You need to download/install the package first on the computer you're developing on, in order to be able to import them in your project. Just like you would download any other third party script which you later add using a script-tag.
When you build your project (npm run build), a vendor.js file will be generated (among others) which includes the some-front-end-library package. This file includes the package which you've installed (and added through Vue.use()).
Your final build (npm run build) will have an index.html file with a <script src="vendor.js" /> tag.
You need to install the module in order to use it. If, for example, you needed vue-tabs-components somewhere in your web app, you are going to need that source code for that module in order to use the tabs.
When it's served to the client, the code gets packaged and bundled so it's true, they don't need npm, but you do as the developer.
And regardless of if you are front-end or not, if you are using Javascript, you're more likely than not going to need NPM at one point in the development process.
If you want to use CDN's, you could check https://cdnjs.com/
There are CDN's of some NPM front end libraries, but it's not always assured you'll find what you're looking for.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
In the past, I made some websites with notepad for example, so we must create a folder TREE and put into it a .htm file, and some folderS with stuff like Javascript, css ...
Maybe I don't understand what NPM really brings, because It seems to do the same thing but automated it ... is it just that ?
For example, why not just unpack a frameworks (e.g. Bootstrap or Kube) without use of NPM and so have folders ready to use ?
Help me to understand please because I'm near the crazy state with all this stuff ...
npm is a package manager for Node.js with hundreds of thousands of packages. Although it does create some of your directory structure/organization, this is not the main purpose.
The main goal, as you touched upon, is automated dependency and package management. This means that you can specify all of your project's dependencies inside your package.json file, then any time you (or anyone else) needs to get started with your project they can just run npm install and immediately have all of the dependencies installed. On top of this, it is also possible to specify what versions your project depends upon to prevent updates from breaking your project.
It is definitely possible to manually download your libraries, copy them into the correct directories, and use them that way. However, as your project (and list of dependencies) grows, this will quickly become time-consuming and messy. It also makes collaborating and sharing your project that much more difficult.
Hopefully this makes it more clear what the purpose of npm is. As a Javascript developer (both client-side and server-side), npm is an indispensable tool in my workflow.
NPM basically is the package manager for node. It helps with installing various packages and resolving their various dependencies. It greatly helps with your Node development. NPM helps you install the various modules you need for your web development and not just given you a whole bunch of features you might never need.
NPM is a Node Package Manager and it's use for
it is an online repository for the publishing of open-source Node.js
projects.
Command line utility to install Node.js packages, do version
management and dependency management of Node.js packages.
NPM is a node package manager. It is basically used for managing dependencies of various server side dependencies.
We can manages our server side dependencies manually as well but once our project's dependencies grow it becomes difficult to install and manage.
By using NPM it becomes easy, we just need to install NPM once for all dependencies.
npm is Node's package manager. It's a repository of hundreds of thousands of useful pieces of code that you may want to integrate with your Node project.
npm also has a command line tool that lets us easily install, manage and run projects.
Use npm to . . .
Adapt packages of code for your apps, or incorporate packages as they are.
Download standalone tools you can use right away.
Run packages without downloading using npx.
Share code with any npm user, anywhere.
Restrict code to specific developers.
Create Orgs (organizations) to coordinate package maintenance, coding, and developers.
Form virtual teams by using Orgs.
Manage multiple versions of code and code dependencies.
Update applications easily when underlying code is updated.
Discover multiple ways to solve the same puzzle.
Find other developers who are working on similar problems and projects.
READ MORE here
It stands for Node Package Manager
I'm introducing unit testing in my project and for this, I need to make myself a package.json file.
First question is, which unit testing suite are you using? I'm looking forward mocha which seem to be pretty much standard for Node.js projects.
Second question is: Is there any magical way of generating a package.json file? (for dependencies and versions)
Third question is: I've been testing a lot of npm packages while developing my project and now I'm stuck with a lot of probably unused packages. Is there any way to tell which one are useless? (I saw npm list installed which is useful though)
I am using Mocha.
npm init
npm ls will list "extraneous" next to ones that are not in your package.json. But, it sounds like you don't have a package.json yet.
Basically, your workflow is very backward. Here is how it is intended to work:
Start a new project with npm init. It has no dependencies.
Oh, I want to start using a package, say express? Add it to package.json under dependencies, then run npm install.
Oh, I want to start using a package for development, say mocha? Add it to package.json under devDependencies, then run npm install.
You seem to have some existing code with manually-installed packages (via npm install <packageName>), which is a mess. I suggest starting over and following the above workflow.
To answer the third question:
npm prune
will remove all installed modules that are no longer mentioned in your package.json.
And you should really have asked 3 separate questions.
I am also using Mocha. It has code coverage, BDD, TDD, runs in browser. It is pretty complete and also heavily maintained by I think one of the most brilliant javascript/node.js programmers named TJ.
It is almost impossible to guess which version(s) to use. Because npm does not know which version breaks which dependencies. You could probably install all dependencies using something like node-detective. Then you can just install them using npm.js from within javascript. Maybe I would like to tackle this in the future.
I would also probably delete all dependencies , next install needed dependencies back using step(2). But also disc-space is not such a big case anymore with the current HDs.
P.S: I think I also agree with Domenic
I am using vows. It's pretty good, but not perfect. I have found unit testing in node to often be challenging because of async callbacks to dbs & such, and have mostly been testing top level functionality.
Here's your magic: Managing Node.js Dependencies with Shrinkwrap.
The only way to know what packages you are using is to know. You can't generate this programmatically. My advice would be to remove packages aggressively, then retest all functionality - if it breaks, you'll know you need to reinstall one of your packages.
Answering your third question, you can use Sweeper to list unused dependencies, and them remove them from your package.json. Just npm install -g sweeper then on your project directory call sweeper on the command line.