I have a node app built with an unknown node and npm version. Is there any way to guess the version, or at least a version range, from package-lock.json?
I do have "lockfileVersion": 1,, which means npm v5 or v6. Any way I can get more granularity?
The reason I need it is, I am getting a bunch of errors like these when running ts-node, unless I delete and rebuild package-lock.json. Which I'd rather not do, for various reasons.
ts.Debug.assert(typeof typeReferenceDirectiveName === "string", "Non-string value passed to `ts.resolveTypeReferenceDirective`, likely by a wrapping package working with an outdated `resolveTypeReferenceDirectives` signature. This is probably not a problem in TS itself.");
Simply search for "#types/node" inside package.json. It will give you node version used. Now search the relative npm version installed for the node version.
"#types/node": {
"version": "16.9.4",
"resolved": "https://registry.npmjs.org/#types/node/-/node-16.9.4.tgz",
"integrity": "sha512-KDazLNYAGIuJugdbULwFZULF9qQ13yNWEBFnfVpql......",
"dev": true
},
Related
Have anyone been in this situation before ?
I run my code with CI/CD
after nest build, it gives me error :
node_modules/#types/superagent/index.d.ts:23:10 - error TS2305: Module '"buffer"' has no exported member 'Blob'. 23 import { Blob } from "buffer";
I don't know why? Please share if you got a solution for this one.
We had the same problem after upgrading nest 7.5.x to 8.0.0. The dependency "supertest" for "nestjs/testing" has a dependency on "#types/supertest" which wildcards "#types/superagent": "*", and that dependency has another wildcard dependency "#types/node": "*", but the types within #types/supertest actually require #types/node >=16.X.X.
So nestjs/testing -> supertest -> #types/supertest -> #types/superagent -> #types/node >= 16.X.X is your problem and error.
The comments mentioned are accurate because these package managers wildcard their dependencies to get the latest version of dependencies. They should but do not add peerDependencies with dependencies requirements such as "#types/node": "">=12.0.0 <16.0.0". Instead they say anything, "#types/node": "*" so the error is post package install, no npm warnings/errors. "It worked yesterday but not today" is your big red flag because when you ran npm install, with these wildcard dependencies even though you did not know it installed the latest version. Since it installed everything wildcard today, but not yesterday, it worked yesterday.
In addition, but also important is that you are have pinned #types/node <16.0.0 thus your error in combination with the other package changes.
One option: revert your package-lock.json changes and run npm ci
Another option: set your package.json dependency for #types/node to -> "#types/node": "^16.0.0",.
Another option: accept that wildcards are wrong and you don't trust what is going on there so pin the #types/superagent dependency to the one prior.
As for me and my family, we use nestjs with AWS lambda which runtime does not include nodejs 16, and not everyone on my team runs npm ci we more typically run npm install so the solution was
package.json
...
"devDependencies": {
...
"#types/node": "14.18.2",
"#types/superagent": "4.1.10",
"#types/supertest": "^2.0.11",
...
Upgrading #types/node to ^14.18.10 and typescript to ^3.9.10 worked for me.
"devDependencies": {
"#types/node": "^14.18.10",
"typescript": "^3.9.10"
},
Found on this discussion from Github
downgrading #types/superagent from v15.x.x to 14.1.14 solved the issue for me. v15 had some performance issues at the typing of this message
"npm i --save #types/superagent#4.1.14" did the trick
One tip is use npm view to get some info.
If you type
npm view #types/node
That shows the ts version compatibility. In my case, Is had to upgrade #types/node to 14.14.31, because I'm using ts 3.4.2.
if you have installed the npm, then delete the node_module file and use yarn install to add the new node_module and vice versa.
So, I've used Parcel multiple times before and I've never had an issue with it.
This time it throws some stupid errors about SemVer versioning and I'm literally loosing my mind trying to find a solution which would fix this problem.
I've started new project: installed npm w/ npm init (no additional options), then installed parcel npm install --save-dev parcel-bundler and then created my folder structure:
--node_modules
--index.html
--index.js
Here is my package.json:
{
"name": "playground",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"dev": "parcel index.html"
},
"author": "",
"license": "ISC",
"devDependencies": {
"parcel-bundler": "^1.12.4"
}
}
I've configured default npm script to run parcel: "dev": "parcel index.html" and run it.
Everything works fine, however when I connect my index.js in index.html via <script src="/index.js"></script> it throws big fat error, saying:
D:\workingSpace\playground\index.js: Invalid Version: undefined
at new SemVer (D:\workingSpace\playground\node_modules\#babel\preset-env\node_modules\semver\semver.js:314:11)
at compare (D:\workingSpace\playground\node_modules\#babel\preset-env\node_modules\semver\semver.js:647:10)
at lt (D:\workingSpace\playground\node_modules\#babel\preset-env\node_modules\semver\semver.js:688:10)
at D:\workingSpace\playground\node_modules\#babel\preset-env\lib\index.js:276:22
at Object.default (D:\workingSpace\playground\node_modules\#babel\helper-plugin-utils\lib\index.js:22:12)
at getEnvPlugins (D:\workingSpace\playground\node_modules\parcel-bundler\src\transforms\babel\env.js:62:34)
at getEnvConfig (D:\workingSpace\playground\node_modules\parcel-bundler\src\transforms\babel\env.js:12:25)
at async getBabelConfig (D:\workingSpace\playground\node_modules\parcel-bundler\src\transforms\babel\config.js:32:19)
at async babelTransform (D:\workingSpace\playground\node_modules\parcel-bundler\src\transforms\babel\transform.js:6:16)
at async JSAsset.pretransform (D:\workingSpace\playground\node_modules\parcel-bundler\src\assets\JSAsset.js:83:5)
Currently I'm using Node v14.6.0 and accordingly it's npm version - 6.14.11
I've never faced this bug before, please help T_T
This is a known problem in the newest version of Parcel.
The solution of this problem was to revert back to version 1.12.3, or by updating to the version 2 of Parcel. You can do the first solution by:
npm uninstall parcel-bundler
npm i --save-dev parcel-bundler#1.12.3
The second solution could be done like this:
npm i --save-dev parcel#next
You might have to refactor your code a bit to prevent breaking changes if you decided to use the nightly version of Parcel. Check more about how to migrate to Parcel v2 / nightly here.
Catch up with that issue here.
Update #1: 28/05/2021
It seems that Parcel team has been working on a fix, as of the time of writing (28/05/2021). While I have not personally checked if the update has worked properly or not, this answer is still very much a viable and feasible solution.
I have recently went through this issue, where parcel#1.12.4 kept throwing Invalid Version: undefined even after trying a very logical workound posted on GitHub #5943.
Installing parcelV2 worked in my case. If anyone else is facing a similar problem, I would recommend trying the following steps:
npm uninstall -D parcel-bundler
npm install -D parcel#next
npx parcel serve index.html
suppose in the package.json file I have my dependencies as-as -
"dependencies": {
"moment": "^2.22.2"
}
Here, are we saying that for the package "moment" we can use any of version 2.x.x functionality( i.e. we can use the new functions provided by 2.23.2 in our app, though we installed 2.22.2 on our computer) or are we saying that anyone else who uses our code of app can use any 2.x.x version of "moment" package ?
If you set:
"moment": "^2.22.2"
the user will download almost the v2.22.2. In this case you will download the v2.24.0
If you set:
"moment": "2.22.2"
the user will download exactly that version
If you set:
"moment": "~2.22.1"
the user will download almost the v2.22.1. In this case you will download the v2.22.2
You can use the functions in v2.9.9 if and only if the module respect the semver standard.
That is true the 99.999% of times.
can we use any of version 2.x.x functionality( i.e. we can use the new functions provided by 2.9.9 in our app, though we installed 2.22.2 on our computer)
Just to avoid confusion. You will not install version 2.22.2 on your computer. By saying ^2.22.2, npm will look what is the highest version of 2.x.x and install that version. You will never install version 2.22.2. You will install version 2.24, and when moment updates its packages to 2.25.0, you will install that version. So you will always have the latest verison 2.x.x installed, so you will get the functions of 2.9.9.
are we saying that anyone else who uses our code of app can use any 2.x.x version of "moment" package ?
Yes, you can verify this by checking out package-lock.json which is created by NPM and describes the exact dependency tree. https://docs.npmjs.com/files/package-lock.json
If your package.json is version 1.0.0 and you have 2.22.2 dependency on moment, and do npm install, you will see in package-lock.
{
"name": "mypackage",
"version": "1.0.0",
"lockfileVersion": 1,
"requires": true,
"dependencies": {
"moment": {
"version": "2.24.0",
"resolved": "https://registry.npmjs.org/moment/-/moment-2.24.0.tgz",
}
}
}
So everybody that installs your version 1.0.0 of your package will get moment version 2.24
why do I need to install "moment.js" again (i.e. update it) once its
installed on my computer –
You don't have to to. But the common rule is to leave node_modules out of repositories and only have package.json. So that when you publish your website to for example AWS, Azure or DigitalOcean, they will do npm install and therefore install everything, every time you publish your website.
To clarify how the flow of packages usually is
You create a package/module with specific verison
I decide to use your package
So I will do npm install (to use your package)
NPM will go through the dependency tree and install versions accordingly.
My website works and I am happy
In the meanwhile you are changing your code, and updating your package.
Few months pass and I decide to change my website. So now when I do npm install (because I updated my code), I will get your updates as well.
I need to know if the following behavior is normal.
When I npm install, each package from my package.json and the dependencies, don't get installed nested anymore, but each dependency is installed in the node_modules directory. That makes my node_modules directory blown and look like this:
This happened since I updated npm and node.
Now I run:
npm -v 3.3.6
node -v 4.2.1
python 2.7
windows 7
wamp
My package.json file looks like this:
{
"private": true,
"devDependencies": {
"gulp": "^3.8.8"
},
"dependencies": {
"laravel-elixir": "^3.0.0",
"bootstrap-sass": "^3.0.0"
}
}
It's the standard laravel package.json file.
Is there a way to have nested directories again, because I don't like such a blown article with over 100 sub directories.
Update: As Erik Pukinskis mentioned in the comments:
As of npm 3.5, support for --legacy-bundling has been dropped.
Yes, there is a way to have nested directories again by changing npm's (version 3 as of this writing) default behaviour:
Delete the currently present node_modules folder.
Tell npm to install with legacy bundling for this one install:
npm install --legacy-bundling
A "permanent" alternative:
Set your npm config to always use legacy bundling...
npm set legacy-bundling=true
.. and run as usual:
npm install
Note: fetching dependencies with legacy bundling will take a lot more time because many several different versions of the same dependencies will be installed.
Disclaimer: As a non-Windows user I have no need for flat dependencies and want to find self-declared dependencies with ease in favour of automatic deduping. Since installing npm dependencies without legacy bundling already takes an incredible amount of time I'm usually willing to spend those extra minutes install time. It gets back down to 5 directories from previously 700+ (...) in a Laravel Elixir setup with bootstrap (non-sass), font-awesome and jquery added.
That's the new behavior of npm 3 as per this npm blog.
I'm having an issue with NPM installing two copies of React in my project. Here are the relevant parts of the dependencies:
My package.json:
"dependencies": {
"react": "0.12.2",
"tcomb-form": "0.4.5"
}
tcomb-form's package.json:
"peerDependencies": {
"react": ">=0.12.0"
}
I would not expect tcomb-form to get it's own copy of React, since I already have a dependency that satisfies its peerDependencies.
However, in npm 2.7.4, it does install a separate version in tcomb-form/node_modules/react, and this version is incompatible with my version (I use 0.12, and it is installing 0.13)
In npm 1.4.28, this behavior was different, and tcomb-form/node_modules/react would not exist, and it would just use my version.
Is there anyway to make it so that we all use the same version of React in the latest npm?
npm dedupe should handle this. In future versions of npm, I believe this will happen during npm install by default, but as of 1.x and 2.x I think a separate dedupe is required.