I have a global bs-platform installation and a local one for a local project. They are in different versions. Everything was fine until today. Every time I try to run my local project, the following error is thrown:
bs-platform version mismatch Running bsb 5.0.4 (/home/jefferson/.nvm/versions/node/v12.4.0/lib/node_modules/bs-platform) vs vendored 4.0.5 (/home/jefferson/astrocoders/lion-carne-client/node_modules/bs-platform)
How can this be solved? I'm using yarn.
You have a few options:
Use the locally installed package
a. Through a script defined in package.json, executed using yarn run or npm run
b. Through executing the command via npx, which comes with npm: npx bsb -make-world
Use the globally installed package by linking it into the project and overwriting any locally installed package of the same name, using either yarn link bs-platform or npm link bs-platform (only needed once per project). node_modules/bs-platform will then be a symlink that points to the globally installed package, hence no version mismatch when running the global bsb.
Related
I moved to a new computer and need to revive old projects (mostly vue, quasar). To do so I run yarn install, then yarn global add #quasar/cli. After the second command I get an error:
error create-strapi-app#4.0.6: The engine "node" is incompatible with this module. Expected version ">=12.22.0 <=16.x.x". Got "18.12.0"
error Found incompatible module.
I did install the strapi cli in a previous project, but I thought that I removed it again using yarn global remove strapi:
> yarn global remove strapi
error This module isn't specified in a package.json file.
So I wonder where the error comes from. I checked the global dir (yarn global dir), but there is no strapi cli neither any strapi package at all.
How can I remove the create-strapi-app error?
(I do not want to change the node version; I want to remove the error.)
I have a yarn/lerna monorepo with multiple packages that depend on each other. If I add packageA as a dependency to packageB and execute yarn install I see that node_modules/packageA is actually a symlink to packages/packageA instead of the published version of that package.
This creates problems on CI if packageB is build before packageA - the build fails because node_modules/packageA just points to the bare sources, without the build products (because packageA has not yet been built).
How can I force yarn to always download the published version of packageA?
yarn --version: 1.22.10
sidenote: If I wanted to use a local version of packageA instead, I would use yarn link or a local path instead of a version in package.json. Why is yarn defaulting to this behaviour?
One options is: "focussed workspaces" - see the guide here.
In my case, I added a file packages/packageB/.yarnrc that specifies to always use the --focus argument for yarn install:
--install.focus true
This will make sure that packageB has a copy of the published packageA in it's own node_modules folder.
However: This only works for one package at a time.
You can just build packages in order of dependencies. So in your case it'd be something like this in your CI (assuming there is a script entry called "build" in package.json of the packages):
yarn workspace packageA run build
yarn workspace packageB run build
This way you control the order of builds,they complete successfully, and you don't have to force using published package.
Problem
I was facing difficulty in importing one of the packages properly and using it in my MERN application in the backend. After researching and looking at the deployed code I got to know that my application is using the unwanted version of that package and thus it is causing the issue but I already changed the version in package.json before pushing. I have written unwanted here because in my case the new version of the package has bugs and that's why I want the old/previous version back but I am unable to know the exact reason or thing which is causing heroku to use the unwanted version again and again.
For Clarity:
initial version: 1.6.6 (was working fine)
then I installed version: 1.7.0 (found bugs) unwanted version
tried to go back to version: 1.6.6 but couldn't
What I have tried
The first thing I tried was setting NODE_MODULES_CACHE to false to avoid heroku from picking up old code as it has worked for me in the past. Apart from that I have I can't find any other thing.
There is nothing suspicious in the heroku logs and it builds the application without any error.
I found the solution to it if someone's looking for it. It is not much of a solution instead it's more about how heroku works.
Heroku uses npm ci instead of npm install.
npm ci installs all dependencies in respect to package-lock.json similar to npm install. The key difference here is that ci doesn't alter package-lock.json under any circumstances.
So basically, the package-lock.json was still the unwanted one in my case and heroku was installing that rather than what I pushed into package.json as it didn't matter.
So, in order to solve this issue you have two options:
You can push your updated package-lock.json. In my case I had intentionally not added package-lock.json to versioning as I thought heroku would update it so I had put it in .gitignore
You can set the USE_NPM_INSTALL environment variable to true to let Heroku know that you want to use npm install instead of npm ci to create the build environment. (NOTE: If you want to use npm install Heroku advises to use NODE_MODULES_CACHE=false as it speeds up the build time)
I went with option 1.
Link to Heroku docs: https://devcenter.heroku.com/articles/nodejs-support
I am having trouble understanding how the -g flag works in NPM. Specifically I'm struggling to understand how it relates to command-line functionality exposed by NPM modules.
I assumed that the difference between installing a package locally and globally was simply that a local package would not be available outside of the particular project. And of course that a globally installed package would be available in any project. I'm from a Rails background so this for me would be similar to installing a gem into a particular RVM versus installing it into the global RVM. It would simply affect which places it was available.
However there seems to be more significance than just scope in NPM. For packages that have command-line functionality, like wait-on, the package (as far as I can tell) is not available on the command line unless it's installed globally.
Local install doesn't make the command-line functionality available:
$ npm install wait-on
$ wait-on
=> -bash: /usr/local/bin/wait-on: No such file or directory
Global install does expose the command-line functionality
$ npm install wait-on -g
$ wait-on
=> Usage: wait-on {OPTIONS} resource [...resource]
Description:
wait-on is a command line utility which will wait for files, ports,
sockets, and http(s) resources to become available (or not available
using reverse flag). Exits with success code (0) when all resources
are ready. Non-zero exit code if interrupted or timed out.
Options may also be specified in a config file (js or json). For
example --config configFile.js would result in configFile.js being
required and the resulting object will be merged with any
Can you expose the command-line functionality using a local install?
Is it possible to install locally but also get the command line functionality? This would be very helpful for my CI setup as it's far easier to cache local modules than global modules so where possible I'd prefer to install locally.
If you are using npm 5.2.0 or later, the npx command is included by default. It will allow you to run from the local node modules: npx wait-on
For reference: https://www.npmjs.com/package/npx
I think you can access locally installed modules from the command line only if you add them to your "scripts" section of your package.json. So to use the locally installed version of wait-on, you can add an entry in "scripts" section of package.json like so "wait-on": "wait-on". Then to run it, you would have to do npm run wait-on. You can also do "wo": "wait-on" and then do npm run wo basically meaning what comes after the run is the script entry. In node_modules, there is a .bin folder and inside of this folder is all the executables that you can access this way.
Installing locally makes the package available to the current project (where it stores all of the node modules in node_modules). This is usually only good for using a module like so var module = require('module'); or importing a module.
It will not be available as a command that the shell can resolve until you install it globally npm install -g module where npm will install it in a place where your path variable will resolve this command.
You can find a pretty decent explanation here.
It is also useful to put commands in the scripts block in package.json as it automatically resolve local commands. That means you could have a script that depended on a package without having an undocumented dependency on the same.
If you need to run it locally on cmd, you have to go inside the node_modules and run from the path.
I'm using serverless to create a Lambda (Node 10x).
The Lambda uses Rollup to create JS and CSS assets. But it is failing at the Rollup stage.
It runs locally using Node 10.0.0 and serverless-offline but once it gets to production, I get this error
2019-08-29T14:32:35.254Z ERROR error: { Error: Missing binding /var/task/node_modules/node-sass/vendor/linux-x64-64/binding.node
Node Sass could not find a binding for your current environment: Linux 64-bit with Node.js 10.x
Found bindings for the following environments:
- OS X 64-bit with Node.js 10.x
This usually happens because your environment has changed since running `npm install`.
Run `npm rebuild node-sass` to download the binding for your current environment.
at error (/var/task/node_modules/rollup/dist/rollup.js:224:15)
at /var/task/node_modules/rollup/dist/rollup.js:17213:17
code: 'PLUGIN_ERROR',
plugin: 'postcss',
id: '/var/task/src/css/app.scss' }
I can run npm rebuild node-sass locally and it does something to my node_modules and makes it bigger, too big in fact to deploy to AWS!
So before I go and rip things out of the app to try and get it to compile at a smaller size, is there anything else I can do regarding this node-sass environment issue?
Thanks
Solved it!
In node_modules/node-sass/vendor/ there was only a darwin-x64-64/binding.node folder/file.
From this github page I downloaded linux-x64-64__binding.node
renamed it to binding.node and created a linux-x64-64 folder and put it in there: node_modules/node-sass/vendor/linux-x64-64/binding.node
Then redeployed the lambda and all is well. I just need to remember to do that if/when I do a yarn update or similar.