Develop Reference

How to import npm javascript Priority Queue library when interviewing with coderpad

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"

Cannot find module 'react-bootstrap/lib/breadcrumb'

Trying to compile a project and being greeted with
Compiling your contracts...
===========================
> Compiling .\src\contracts\TokenFarm.sol
> Artifacts written to C:\Users\sean\AppData\Local\Temp\test--17472-6fYHF170F1H9
> Compiled successfully using:
- solc: 0.5.16+commit.9c3226ce.Emscripten.clang
Error: Cannot find module 'react-bootstrap/lib/Breadcrumb'
Require stack:
I've tried manually installing the package with
npm install --save Breadcrumbs
But I can't seem to find the correct link to download the library
Is there a way to install an older version of node because I believe the repo I'm cloning from is from a few years ago so there could be some dependency issues going on.

You don't need to downgrade your node version. It appears your react-bootstrap has been updated with a major release, without updating related references.
To fix this, either downgrade your library version as suggested by Drew Reese, or just fix your imports.
If you look over the library codebase, you can see you should now import your components through react-bootstrap/src/Breadcrumb instead.

Importing in Node.js: error "Must use import to load ES Module" [duplicate]

This question already has answers here:
SyntaxError: Cannot use import statement outside a module
(34 answers)
Closed last year.
I'm trying to import myArr from hello.js into index.js. However I get an error of
Error [ERR_REQUIRE_ESM]: Must use import to load ES Module
File hello.js
export let myArr = ['hello', 'hi', 'hey'];
File index.js
import { myArr } from './hello.js';
console.log(myArr);
Where am I going wrong?

Use version 2:
npm install node-fetch#2
node-fetch from v3 is an ESM-only module - you are not able to import it with require().
If you cannot switch to ESM, please use v2 which remains compatible with CommonJS. Critical bug fixes will continue to be published for v2.

I ran your code without any problems. Check for two things:
Node.js version >= 14. It only works with the latest version of Node.js.
Make sure your package.json includes a line for "type": "module". Without this line, Node.js assumes you want to use CommonJS modules rather than ESM.

I ran into a similar issue while building my React project.
Here's the error:
ERROR in ./src/index.js
Module build failed (from ./node_modules/babel-loader/lib/index.js):
Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /home/pradeep/Work/my_project/node_modules/#babel/runtime/helpers/interopRequireWildcard/_index.mjs
Then I realized that I am on a different Node.js version than the one used to install packages in this project.
I had two options:
Change Node.js version to the one required by this project and build again.
Stay on the Node.js version you have and remove the node_modules directory and package-lock.json file and do npm install again.
I chose the first approach and it worked for me.

If you have Node.js version lower than 14, e.g., v12 - you must specify this flag:
node --experimental-modules your.mjs

I use nvm to install the latest stable version of Node.js.
To delete the package-lock.json file and the node_modules folder, run npm. I then npm start to solve my problem.

Rename hello.js to hello.mjs.
You are using CommonJS right now with the .js extension. To import ES6 modules, you will have to change the extension of the file that you want to import to .mjs so it knows that it is an ES6 module.

The problem is that Node.js does not currently support import and export natively yet. It is still experimental according to the documentation. I recommend you use Babel to compile your code and allow you to use import and export.
For example, you can install the #babel/node package and run your project using:
npx babel-node index.js
Here are the documentation for #babel/node. Like the documentation state, this command is only meant for local development. In production, they recommend a configuration like this.

Import date-fns with npm

I am new to web dev and am following a JS tutorial that is only 1 year old but uses outdated instructions for importing the JS library date-fns with a CDN. I love CDNs, unfortunately only an npm package is available now (link to documentation).
I made sure npm was updated then installed date-fns to the desired directory with the following line in terminal:
npm install date-fns --save
There are no more instructions on how to use the package except this example, which I assume goes in the JS file and not the html:
import { formatDistance, subDays } from 'date-fns'
... but using this syntax to try to import the isToday method from the package gives the following warning in my Chrome console:
Uncaught SyntaxError: Cannot use import statement outside a module
This question is asked elsewhere, but there is so much npm-related jargon in those answers I couldn't tell what I was supposed to do. Also, the code was different and older. Does 'module' refer to the npm package?
One would hope a one-year-old tutorial would be new enough to follow. Alas, earwax.

You can get the CDN build of date-fns here: https://cdnjs.cloudflare.com/ajax/libs/date-fns/1.30.1/date_fns.js
The import/export won't work in browsers natively, especially if you're trying to work with npm packages. Since you're a beginner, I don't want to confuse you but import/export works in a specific scenario. You can read more about that here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules
Once you're acquainted with web dev, you can try using a bundler such as Parcel which allows you to use npm packages and combine them into a single JS file that can be used in the web: https://parceljs.org/

Node / npm: How to manage globally installed devDependencies

I'm building a Node module with devDependencies that should be globally installed, such as jasmine-node and jshint. What I essentially need is to be able to reference their binaries in my makefile / npm scripts section to run tests, lint, etc. In other words I do not wish to require() them programmatically.
After digging around I'm still confused on how to handle this:
1) My first approach was to assume that these modules would be globally installed, clarify this in my module's documentation and reference their binaries as globals - i.e. expect them to be globally available. This conflicts with this piece of advice
Make sure you avoid referencing globally installed binaries. Instead, point it to the local node_modules, which installs the binaries in a hidden .bin directory. Make sure the module (in this case "mocha") is in your package.json under devDependencies, so that the binary is placed there when you run npm install.
(taken from this post)
This generally sounds right, as the aforementioned setup is rather fragile.
2) My next approach was explicitly including those modules in devDependencies (although they are still globally installed on my system (and most probably on users' & contributors' systems as well)). This ensures that appropriate versions of the binaries are there when needed and I can now reference them through node_modules/.bin/.
However I'm now in conflict with this piece of advice
Install it locally if you're going to require() it.
(taken from npm docs)
Regardless of that, I do notice that npm install will now actually fetch nothing (display no network activity) for the globally installed modules.
My questions:
Are the local versions of globally installed modules (that are mentioned in devDependencies) just snapshots (copies) of the global ones, taken during npm install?
Is 2) the correct way to go about doing this? or is there some other practice I'm missing?

Here's my personal take on this, which is decidedly divergent from node.js common practice, but I believe it is an overall superior approach. It is detailed in my own blog post (disclaimer about self-promotion, yada yada) Managing Per-Project Interpreters and the PATH.
It basically boils down to:
Never use npm -g. Never install global modules.
Instead, adjust your PATH to include projectDir/node_modules/.bin instead

Revisiting my own question a couple of years after it was originally written, I feel I can now safely say that the quoted 'advice'
Install it locally if you're going to require() it.
does not stand anymore. (It was part of the npm docs but the posted 2-year old link gives me a 404 at the time of this writing.)
Nowadays, npm run is a fine way to do task management / automation and it'll automatically export modules which are installed locally, into the path before executing. Thus, it makes perfect sense to locally install modules that are not to be require()d such as linters and test-runners. (By the way, this is completely in line with the answer that Peter Lyons provided a couple of years ago - it may have been 'decidedly divergent from node.js common practice' back then, but it's pretty much widely accepted today :))
As for my second question
Are the local versions of globally installed modules (that are mentioned in devDependencies) just snapshots (copies) of the global ones, taken during npm install?
I am pretty confident that the answer is No. (Perhaps the lack of network activity that I was observing back then, during the installation of local modules which were also globally installed was due to caching..?)
Note, Nov 12 2016
The relevant npm docs to which the original question linked have moved here.