Error on installing NoRedInk/elm-decode-pipeline with Elm 0.19.1 - elm

I'm working through an example on elmprogramming.com and am stuck on installing the elm-decode-pipeline package. Specifically when I
elm install NoRedInk/elm-decode-pipeline
I get the following message
-- CANNOT FIND COMPATIBLE VERSION ------------------------------------- elm.json
I cannot find a version of NoRedInk/elm-decode-pipeline that is compatible with
your existing dependencies.
Perhaps this is because Elm moved from 0.19.0 to 0.19.1? Or perhaps I'm doing something wrong? My elm.json is
{
"type": "application",
"source-directories": [
"src"
],
"elm-version": "0.19.1",
"dependencies": {
"direct": {
"elm/browser": "1.0.2",
"elm/core": "1.0.2",
"elm/html": "1.0.0",
"elm/http": "2.0.0",
"elm/json": "1.1.3"
},
"indirect": {
"elm/bytes": "1.0.8",
"elm/file": "1.0.5",
"elm/time": "1.0.0",
"elm/url": "1.0.0",
"elm/virtual-dom": "1.0.2"
}
},
"test-dependencies": {
"direct": {},
"indirect": {}
}
}
What should I do to install the package? Thanks for any help!

It's just moved. The package is now at NoRedInk/elm-json-decode-pipeline.
You definitely can't be blamed for being confused though. There is no indication of this in the package documentation, only in the description of the source code repository, and there's also no indication that the old package only works with 0.18. Unfortunately this is just the state of the package ecosystem at the moment, and fixing it does not seem to have much priority.
The best way to make sure you have a package that works for 0.19 is to search for it on the package site. Everything that pops up there should work for 0.19, as you have to use a different search for 0.18 packages.

Related

WebdriverIO : Can we push code with dependencies only installed?

I am using webdriverIO v6
I have Installed just these two packages: npm install #wdio/cli as well as webdriverio
my tests are ruining smoothly in my local.
Is this ok to push to code-repo in git, does this work in Jenkis or Azure devops?
or is is required to install the --save-dev too to work in CI tools?
{
"name": "test-package",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"wdio": "./node_modules/.bin/wdio wdio.conf.js"
},
"author": "",
"license": "ISC",
"devDependencies": {
"#wdio/allure-reporter": "^6.1.23",
"#wdio/cli": "^6.1.25",
"#wdio/local-runner": "^6.1.25",
"#wdio/mocha-framework": "^6.1.19",
"#wdio/spec-reporter": "^6.1.23",
"#wdio/sync": "^6.1.14",
"chromedriver": "^83.0.1",
"wdio-chromedriver-service": "^6.0.3",
"webdriverio": "^6.1.25"
},
"dependencies": {}
}
This is nothing specific to wdio. This is a question which has been discussed multiple times in nodejs context.
Many developers suggest not to include node_modules in the repo because of various reasons which are logical. Then there are reasons which might force you to do it. if you are doing it just to reduce the build time, be prepared for other implications. Below are links which might help you.
https://flaviocopes.com/should-commit-node-modules-git/
Should "node_modules" folder be included in the git repository

Error installing #tensorflow/tfjs-node

I'm following a ML tutorial on Youtube (https://www.youtube.com/watch?v=XdErOpUzupY&index=5&list=PLoYCgNOIyGABWLy_XoLSxTVRe2bltV8GM) and I'm suppose to install #tensorflow/tfjs-node. However when I run
npm install #tensorflow/tfjs-node
I get the following error (see screencap).
I've watched the relevant files be placed into node_modules but then they immediately get uninstalled. I'm not sure where to go from here, but let me know if you need anymore info.
Cheers
Package.json
{
"name": "tfjs",
"version": "1.0.0",
"description": "",
"main": "iris.js",
"scripts": {
"start": "parcel --target=node iris.js & nodemon dist/iris.js"
},
"keywords": [],
"author": "",
"license": "ISC",
"dependencies": {
"#tensorflow/tfjs": "^0.11.7",
"#tensorflow/tfjs-node": "^0.1.7",
"nodemon": "^1.17.5",
"parcel": "^1.9.0"
}
}
Given the error screenshot of your errors, you're using node version 6 whereas tensorflowjs requires node v8.9+. Consider upgrading the version of your server node using the official website here. When you're done check the version with node -v to make sure that your version of node meets the requirements of tensorflowjs modules.

NPM - How do I override one of my dependencies dependency? [duplicate]

I would like to use the grunt-contrib-jasmine NPM package. It has various dependencies. Part of the dependency graph looks like this:
─┬ grunt-contrib-jasmine#0.4.1
│ ├─┬ grunt-lib-phantomjs#0.2.0
│ │ ├─┬ phantomjs#1.8.2-2
Unfortunately, there's a bug in this version phantomjs which prevents it from installing correctly on Mac OS X. This is fixed in the latest version.
How can I get grunt-lib-phantomjs to use a newer version of phantomjs?
Some additional context:
grunt-contrib-jasmine explicitly requires version "~0.2.0" of grunt-lib-phantomjs, which explicitly requires version "~1.8.1" of phantomjs.
Adding phantomjs to my package's dependencies first has no effect; both versions are installed and grunt-contrib-jasmine still uses the older versions (see: When installing a package with NPM, can you tell it to use a different version of one of its dependencies?).
You can use npm shrinkwrap functionality, in order to override any dependency or sub-dependency.
I've just done this in a grunt project of ours. We needed a newer version of connect, since 2.7.3. was causing trouble for us. So I created a file named npm-shrinkwrap.json:
{
"dependencies": {
"grunt-contrib-connect": {
"version": "0.3.0",
"from": "grunt-contrib-connect#0.3.0",
"dependencies": {
"connect": {
"version": "2.8.1",
"from": "connect#~2.7.3"
}
}
}
}
}
npm should automatically pick it up while doing the install for the project.
(See: https://nodejs.org/en/blog/npm/managing-node-js-dependencies-with-shrinkwrap/)
As of npm cli v8.3.0 (2021-12-09) this can be solved using the overrides field of package.json. As described in StriplingWarrior's answer
For example, the project has typescript version 4.6.2 as direct development dependency and awesome-typescript-loader that uses old version 2.7 of typescript. Here is how you can tell npm to use version 4.6.2 of typescript for awesome-typescript-loader:
{
"name": "myproject",
"version": "0.0.0",
"scripts": ...
"dependencies": ...
"devDependencies": {
"typescript": "~4.6.2",
"awesome-typescript-loader": "^5.2.1",
...
},
"overrides": {
"awesome-typescript-loader": {
"typescript": "$typescript"
}
}
}
If you don't use typescript as direct development dependency, then you have to write 4.6.2 instead of $typescript in overrides section:
{
"name": "myproject",
"version": "0.0.0",
"scripts": ...
"dependencies": ...
"devDependencies": {
"awesome-typescript-loader": "^5.2.1",
...
},
"overrides": {
"awesome-typescript-loader": {
"typescript": "~4.6.2"
}
}
}
For using the latest version of dependency:
{
"name": "myproject",
"version": "0.0.0",
"scripts": ...
"dependencies": ...
"devDependencies": {
"awesome-typescript-loader": "^5.2.1",
...
},
"overrides": {
"awesome-typescript-loader": {
"typescript": "latest"
}
}
}
Same overrides can be used for both dependencies and devDependencies.
If you're using npm version >5 but <8.3.0: edit your package-lock.json: remove the library from "requires" section and add it under "dependencies".
For example, you want deglob package to use glob package version 3.2.11 instead of its current one. You open package-lock.json and see:
"deglob": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/deglob/-/deglob-2.1.0.tgz",
"integrity": "sha1-TUSr4W7zLHebSXK9FBqAMlApoUo=",
"requires": {
"find-root": "1.1.0",
"glob": "7.1.2",
"ignore": "3.3.5",
"pkg-config": "1.1.1",
"run-parallel": "1.1.6",
"uniq": "1.0.1"
}
},
Remove "glob": "7.1.2", from "requires", add "dependencies" with proper version:
"deglob": {
"version": "2.1.0",
"resolved": "https://registry.npmjs.org/deglob/-/deglob-2.1.0.tgz",
"integrity": "sha1-TUSr4W7zLHebSXK9FBqAMlApoUo=",
"requires": {
"find-root": "1.1.0",
"ignore": "3.3.5",
"pkg-config": "1.1.1",
"run-parallel": "1.1.6",
"uniq": "1.0.1"
},
"dependencies": {
"glob": {
"version": "3.2.11"
}
}
},
Now remove your node_modules folder, run npm ci (or npm install for old version of node/npm) and it will add missing parts to the "dependencies" section.
As of NPM v8.3, the correct way to deal with this is via the overrides section of your package.json file.
If you need to make specific changes to dependencies of your
dependencies, for example replacing the version of a dependency with a
known security issue, replacing an existing dependency with a fork, or
making sure that the same version of a package is used everywhere,
then you may add an override.
Overrides provide a way to replace a package in your dependency tree
with another version, or another package entirely. These changes can
be scoped as specific or as vague as desired.
To make sure the package foo is always installed as version 1.0.0 no
matter what version your dependencies rely on:
{
"overrides": {
"foo": "1.0.0"
}
}
There are a variety of other, more nuanced configurations allowing you to only override a package when it's a dependency of a particular package hierarchy. For more details, check out https://docs.npmjs.com/cli/v8/configuring-npm/package-json#overrides
The only solution that worked for me (node 12.x, npm 6.x) was using npm-force-resolutions developed by #Rogerio Chaves.
First, install it by:
npm install npm-force-resolutions --save-dev
You can add --ignore-scripts if some broken transitive dependency scripts are blocking you from installing anything.
Then in package.json define what dependency should be overridden (you must set exact version number):
"resolutions": {
"your-dependency-name": "1.23.4"
}
and in "scripts" section add new preinstall entry:
"preinstall": "npm-force-resolutions",
Now, npm install will apply changes and force your-dependency-name to be at version 1.23.4 for all dependencies.
For those using yarn.
I tried using npm shrinkwrap until I discovered the yarn cli ignored my npm-shrinkwrap.json file.
Yarn has https://yarnpkg.com/lang/en/docs/selective-version-resolutions/ for this. Neat.
Check out this answer too: https://stackoverflow.com/a/41082766/3051080
Nested replacement with an entirely different package
Most of the strategies outlined in the other answers here work well if you are just interested in overriding the package's version number, but in our case, we needed to find a way to override a nested npm sub-dependency with a different package altogether. For details on why you would ever want to do this, please refer to the following question:
How to override a nested npm sub-dependency with a different package altogether (not just different package version number)?
Specify the tarball directly
For nested replacement of a package with an entirely different package using the npm-force-resolutions strategy that others have mentioned, you just need to provide a link to the tarball where you would normally specify the overriding version number.
As an example, for the case of replacing the vulnerable package, ansi-html, with the fixed fork of this package, ansi-html-community, your resolutions section of package.json should look like this:
"resolutions": {
"ansi-html": "https://registry.npmjs.org/ansi-html-community/-/ansi-html-community-0.0.8.tgz"
}
To find the link to the tarball, use the following command, modifying your registry as necessary:
npm view ansi-html-community dist.tarball --registry=https://registry.npmjs.org/
Also, note that for npm-force-resolutions to work when you run npm install, you will need a preinstall entry under the scripts section of package.json:
"scripts": {
"preinstall": "npx npm-force-resolutions"
}
#user11153 's answer worked for me locally, but when trying to do a clean install (aka deleting node_modules), I would get:
npm-force-resolutions: command not found
I had to update the preinstall script to be:
"preinstall": "npm i npm-force-resolutions && npm-force-resolutions"
Which ensures that npm-force-resolutions package is installed before attempting to run it.
That being said, if you're able to use yarn instead, I would do that and then use #Gus 's answer.
I had an issue where one of the nested dependency had an npm audit vulnerability, but I still wanted to maintain the parent dependency version. the npm shrinkwrap solution didn't work for me, so what I did to override the nested dependency version:
Remove the nested dependency under the 'requires' section in package-lock.json
Add the updated dependency under DevDependencies in package.json, so that modules that require it will still be able to access it.
npm i
I was about to go down the npm-force-resolutions route but it seems that simply including the dependency in my own package.json fixed the problem for me.
I believe this worked in my case because the original dependency allows for patch versions of the dependency in question that I wanted to update. Thus by manually including a newer version it still fulfilled the dependency of the original dependency and will use the one I've manually added.
Example
Problem
I need to update plyr to version 3.6.9 from 3.6.8
Mine
package.json
{
"dependencies": {
"react-plyr": "^3.2.0"
}
}
React Plyr
package.json
{
"dependencies": {
"plyr": "^3.6.8"
}
}
Notice for the plyr dependency it starts with ^ this means it can accept any minor patches. You can learn more about that here:
https://docs.npmjs.com/about-semantic-versioning#using-semantic-versioning-to-specify-update-types-your-package-can-accept
Updating Mine
This updates the plyr dependency from my package.json.
package.json
{
"dependencies": {
"plyr": "^3.6.9",
"react-plyr": "^3.2.0"
}
}
Based on the rest of the answers, I provide the same solution, but I display the package.json, as I struggled a little bit on where to place the override and how.
{
"name": "my-app",
"version": "snapshot",
"scripts": {
"ng": "ng",
"build-dev": "ng build --configuration development",
},
"private": true,
"dependencies": {
"#angular/animations": "~14.2.9",
"#angular/common": "~14.2.9"
...
},
"devDependencies": {
"#angular-devkit/build-angular": "^14.2.8",
....
},
"overrides": {
"loader-utils#>2.0.0 <3": "2.0.4",
"loader-utils#>3.0.0 <4": "3.2.1"
}
}
For November 2022 "loader-utils" security vulnerability, it was requested to
use the version 2.0.4, if you are in the 2.X
use the version 3.2.1, if you are in the 3.X
And to verify
add the package.json the override tag
delete the package-lock.json
run "npm install"
run "npm audit"
Run this first
npm i -D #types/eslint#8.4.3
it will solve the issue

Adding Microsoft.EntityFrameworkCore.Tools to a ASP.NET Core project

I am creating a new ASP.NET Core project using dotnet 4.5.2 and am trying to add a reference to Microsoft.EntityFrameworkCore.Tools. In my project.json file I have these listed under dependencies:
"Microsoft.EntityFrameworkCore.SqlServer": "1.0.0",
"Microsoft.EntityFrameworkCore.Tools": "1.0.0-preview2-final"
Looking under References, they appear to be successfully loaded. I then added this under tools in project.json:
"Microsoft.EntityFrameworkCore.Tools": {
"imports": [ "portable-net451+win8" ],
"version": "1.0.0-preview2-final"
}
After I added that, when I build the solution I get this build error:
Could not find a part of the path 'C:\Users\(my user name)\.nuget\packages\.tools\Microsoft.EntityFrameworkCore.Tools'
I get the same error if I remove the imports line. What am I doing wrong here?
Just ran into the same issue.
I fixed the issue by installing the tools package again in the package manager console:
Install-Package Microsoft.EntityFrameworkCore.Tools –Pre
Before reinstalling the package was actually missing in the .nuget\packages.tools folder, after reinstalling it was there.
I followed the https://docs.efproject.net/en/latest/platforms/aspnetcore/new-db.html tutorial, but I think I installed the package in the wrong order or initially forgot to reference the EF.tools package in the "tools" section of the project json.
I had this same problem and just solved using the examples from the EF Core setup guide from Microsoft, checking their GitHub code as well, I found this to work for the project.json.
I had to remove the imports from the "frameworks" property, which means no Application Insights for now. Once I did this and built, the folder appeared in the tools folder. Sorry I'm not good at posting code here but here are the important parts, ... elipses used to trim the post of my other things:
"dependencies": {
...
"Microsoft.EntityFrameworkCore": "1.0.0",
"Microsoft.EntityFrameworkCore.SqlServer": "1.0.0",
"Microsoft.EntityFrameworkCore.SqlServer.Design": "1.0.0",
"Microsoft.EntityFrameworkCore.Tools": {
"version": "1.0.0-preview2-final",
"type": "build"
} ...},
"tools": {
"Microsoft.EntityFrameworkCore.Tools": "1.0.0-preview2-final",
"Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.0.0-preview2-final"
},
"frameworks": {
"netcoreapp1.0": {
}...
I had the same issue and had to add the following to my project.json.
"Microsoft.EntityFrameworkCore.SqlServer.Design": "1.1.0-preview1-final"
The only difference is that I'm working with the newly release .NET Core 1.1, ASP.NET 1.1 and Entity Framework 1.1.
I had the same issue and tried many things. I found out that Design and Tools need to be the same version but intellisense was not giving me options common to both packages. Then I found this article and tried its code.
https://learn.microsoft.com/en-us/ef/core/miscellaneous/cli/dotnet
Using the following code from that article solved the issue for me;
"dependencies": {
"Microsoft.EntityFrameworkCore.Design": {
"type": "build",
"version": "1.0.0-preview2-final"
}
"Microsoft.EntityFrameworkCore.Tools": {
"type": "build",
"version": "1.0.0-preview2-final"
},
},
...
"tools": {
"Microsoft.EntityFrameworkCore.Tools": "1.0.0-preview2-final"
},
My problem was I had Microsoft.EntityFrameWorkCore.Tools instead of Microsoft.EntityFramework.Tools, note the lowercase w.

Using the FileAPI library with browserify

The FileAPI library (https://github.com/mailru/FileAPI/issues/202) does not officially support CommonJS modules. I've tried using browserify-shim but I'm not able to make it work. After requireing fileapi I just get an empty object back. I've created a repo for reproduction here https://github.com/Prinzhorn/browserify-fileapi
Relevant package.json part
{
"dependencies": {
"fileapi": "2.0.15"
},
"devDependencies": {
"browserify": "11.1.0",
"browserify-shim": "3.8.10"
},
"browser": {
"fileapi": "./node_modules/fileapi/dist/FileAPI.html5.js"
},
"browserify-shim": {
"fileapi": "FileAPI"
}
}
If you want to try it locally:
git clone git#github.com:Prinzhorn/browserify-fileapi.git
npm install
npm run build
chromium-browser index.html
Check out the console in Chromium, you'll see an empty array from running console.log(Object.keys(require('fileapi'))). Note that there is a global window.FileAPI with the correct API.
Does anyone know if browserify-shim is able to shim FileAPI? Because I believe it does some exotic things to manage it's dependencies (the concatenated files expect certain globals).
You'll need to tell browserify to use browserify-shim as a transform in the package.json as outlined in this example
Mainly you're missing:
"browserify": {
"transform": [ "browserify-shim" ]
}