I found some code on this site that works well, it does this:
process.stdin.pipe(require('split')()).on('data', function(line) {
...
Curiously no split npm package is installed locally or globally. I search and can't find such a package in official node.js docs.
So I'm curious about where to find information about it. Sure, there's a split npm package that exists, and it does support what my code seems to be doing with it, but... the dots don't connect, because I never had to npm install it!
How do I figure out where the javascript source code for split is on my system? Maybe split has somehow been "included" in the "standard" node.js library and the documentation just needs to catch up?
Additional info:
$ node
> require ('split')
[Function: split]
> process.version
'v6.9.2'
>
I realize now that npm ls shows split exists deep in the dependencies in this project. So that is probably where it is being pulled in from.
The answer to my specific situation is that I was using npm ls --depth=0 and didn't see split in it, but it's a dependency several levels deep inside the project, and require obviously is able to find it that way, and it was simply a coincidence (no manual install of split ended up being necessary)
Related
so Leetcode already supports #datastructures-js/priority-queue which is why I could just use
let heap = new MinPriorityQueue()
out of the box. But then I realized when I interview with coderpad or hackerrank, I probably won't have access to the npm package I will need to use these datastructures out of the box like this.
Any advice on how I can make that happen?
I looked at coderpad documentation - and they say I can install any npm package I want, but so far have not found the right way to do it. Any help appreciated!
https://coderpad.io/languages/frontend-frameworks/
CoderPad supports npm command usage via the shell. This means that you can npm i any version of any library in the package ecosystem. You can also create an .npmrc file to customize the install logic of npm.
The shell seems to only be available in "frontend frameworks".
When you select a frontend framework to code in, you’ll notice a multi-pane window that’s similar to what you’d find in popular IDEs.
... The third pane provides an interactive shell, server log output, and a console.
Picking HTML worked for me. It does give you a main.js file, although the regular output window is no longer and there is Console and Logs instead, so it's not quite as convenient as a straight javascript environment.
In Shell:
Starting shell...
~/app $ npm install --save #datastructures-js/priority-queue
added 2 packages, and audited 92 packages in 2s
8 packages are looking for funding
run `npm fund` for details
found 0 vulnerabilities
In main.js:
import {
PriorityQueue,
MinPriorityQueue,
MaxPriorityQueue,
ICompare,
IGetCompareValue,
} from '#datastructures-js/priority-queue';
let heap = new MinPriorityQueue()
console.log(heap)
Then click Run and check Console to see:
MinPriorityQueue {_heap: MinHeap, constructor: Object}
_heap: MinHeap
<constructor>: "MinPriorityQueue"
I've got a task that involves writing a code and I carried it out quite easily. I need to submit my solution to GitHub – according to the plan, I forked a certain repository and even cloned it to my hard drive using VS code. However, I was also told to install NPM dependencies to that newly created folder.
There are many manuals on Internet, but almost no one of them explains how to do it in a comprehensible way. As a beginner, I often struggle with all these new keywords, commands, etc and I would like to make things somewhat clearer. Do you have an idea how to get through it?
If you have already installed npm, in project directory use command
npm install
You can start with npm init in your folder. Then package.json file will be created. you can add dependencies you want to add, and run npm install.
In a team set up, usually, I have faced merge conflicts in package-lock.json and my quick fix has always been to delete the file and regenerate it with npm install. I have not seriously thought about the implication of this fix because it has not caused any perceivable problem before.
Is there a problem with deleting the file and having npm recreate it that way instead of resolving the conflicts manually?
Yes, it can and will affect all the project in really bad way.
if your team does not run npm install after each git pull you all are using different dependencies' versions. So it ends with "but it works for me!!" and "I don't understand why my code does not work for you"
even if all the team runs npm install it still does not mean everything is ok. at some moment you may find your project acts differently. in a part that you have not been changing for years. and after (probably, quite painful) debugging you will find it's because of 3rd level dependency has updated for next major version and this led some breaking changes.
Conclusion: don't ever delete package-lock.json.
Yes, for first level dependencies if we specify them without ranges (like "react": "16.12.0") we get the same versions each time we run npm install. But we cannot say the same about dependencies of 2+ level deep (dependencies that our dependencies are relying on), so package-lock.json is really important for stability.
In your case you better do next way:
fix conflicts in package.json
run npm install
As easy as it looks. The same to yarn - it fixes lockfile conflict on its own. The only requirement here to resolve all the conflicts in package.json beforehand if any.
Per docs npm will fix merge conflicts in package-lock.json for you.
[Upd from 2021] important! If you use some library already and npm/GitHub account of its maintainer is hacked. And new version with malicious code inside is released. And you have package-lock.json intact. You will be fine. If you drop it you are in trouble.
Yes it can have bad side effects, maybe not very often but for example you can have in package.json "moduleX": "^1.0.0" and you used to have "moduleX": "1.0.0" in package-lock.json.
By deleting package-lock.json and running npm install you could be updating to version 1.0.999 of moduleX without knowing about it and maybe they have created a bug or done a backwards breaking change (not following semantic versioning).
Anyway there is already a standard solution for it.
Fix the conflict inside package.json
Run: npm install --package-lock-only
Check out this link for more info:
https://docs.npmjs.com/cli/v6/configuring-npm/package-locks#resolving-lockfile-conflicts
I know it's an old question but for future seekers, you can also use npm-merge-driver which try to automatically resolve the npm related files' merge issues.
Just install it globally npx npm-merge-driver install --global. You can read more about it here npm-merge-driver
Edit: Just want to warn people, who are interested in using above package, that sometime it can behave erratically and difficult to remove. So although it is a useful tool, it still need some work.
Edit: This repository is now archived and read only.
npm i --force does the work for me
I've been reading up on the npm left-pad fiasco, but I'm somewhat confused by how it happened. I think I have a misunderstanding of how npm actually works. If the developer of left-pad unpublished the package, I assume npm install left-pad wouldn't work anymore. However, for users who had already installed it, won't left-pad still be in the node_modules folder? Wouldn't the developers of say, Babel, have to remove and reinstall left-pad for npm to realize that the package has disappeared? I am clearly missing something, but I'm not sure what.
When I run npm install babel, left-pad is not bundled in babel but rather is expressed as dependency in it's package.json file. So npm then has to go find left-pad and download it as well. So if you were installing left-pad or anything using left-pad for the first time, you wouldn't be able to. While this means you're safe if it already exists in your local directory, the project would fail to build properly as soon as it is built somewhere else. For example, a CI server that does a clean build from scratch for each new changeset would fail to build any project that relies on left-pad. Or if you were checking out a project for the first time, or deploying it to a new server, you wouldn't be able to build.
This is simple to fix if you were relying on left-pad directly. Just write a replacement and update your code to use the replacement. But when it's required deep in your dependency tree, say by Babel, it's unlikely you can refactor Babel or other modules on your own to use a left-pad replacement. You'd have to wait for all of the various node module developers to update their modules with something else and republish.
It's not as apocalyptic as news articles made it sounds, but it is a huge inconvenience and throws a wrench in many systems outside of developer workspaces where left-pad was already cached.
As #Lazar said, you understood correctly.
The problem come in that, if Babel is relying on left-pad, and am trying to install Babel, it will fail.
Well, I could always rewrite it myself as a workaround.
But if it is a module used by a module used by a module used by... used by Babel, or more module, you face a real nightmare, because Babel can't do anything, nor can you, and you are forced to wait that every single module develloper relying on left-pad update their code.
I want to query a hive database table from node js. I searched in npm and found two packages - node-hive and thrift-hive, but problems with both as follows
1) node-hive: When I try to run using this, there are many missing dependencies finally didn't get the module 'thrift/transport'
2) thrift-hive: When I try to run using this, query is running forever and not even doing a timeout. I suspect that the libraries they used are for old versions of hive.
The version we are using for hive is 1.1.0-cdh5.4.1.
Is there anything I am missing or is there any proper hive connectors in npm. Thanks in advance
If you want to resolved that dependencies issue then you need to first install thrift module with 0.9.1 version.
So add "thrift":"0.9.1" in your package.json and run npm install.
After that you will not get 'thrift/transport' module dependencies error. Furthermore, even I am curious to know about which npm is best suitable to connect to hive. I am using node version 0.12.7.