I follow and try same sample code in this instruction
Playground tutorial
but when I submit a transaction Error: Could not find any functions to execute for transaction org.acme.mynetwork.Trade#d77dbd2d-53e3-4435-b4fb-d802d5bd6bec.
Anyone have any idea?
This may have been an error you saw in Playground in v0.14.3. Suggest to update (ie re-install) your Composer dev environment to the current release v0.15.0 (as of Nov 10th) - there is a new tutorial (its changed from what you saw) and it will use Business network cards for the network deploy (createComposerProfile.sh is no longer needed) - makes life easier. To get the latest version, you will need to install the modules as per the docs -> https://hyperledger.github.io/composer/installing/development-tools.html - this will get the latest release. Make sure you do a full teardown using the scripts you downloaded in fabric-tools (as your CC containers will be 0.14.3 or earlier and thus out of date) and that you then subsequently, do an npm -g uninstall of the same module names eg composer-cli, composer-playground etc and such that they are all at the same level (0.15.0) upon subsequent npm -g install of same composer modules.
Related
I've created a React-Native application as of 0.70.6, went through the grief of cocoapods and everything that comes with development on Apple's silicon chips (M2) and got it working and have done quite a bit of work on the project, and then (after creating a GitHub repo) handed it off to a coworker to do some design work (who is on an M1) ...had many issues on their machine as well, but eventually got it working. Now, React-Native 0.71.0 has been released and I ran through all of the steps to upgrade it and got it working on my M2 machine, no issues at all, but after pushing and getting it on their machine, I have not been able to find a solution to the pod install failing due to the hermes-engine not being able to load, a couple of the errors that pop up are,
[!] Failed to load 'hermes-engine' podspec:
[!] Invalid `hermes-engine.podspec` file: undefined method 'exists?' for FileClass.
I have been searching all day for what this means (I am fairly new to React-Native ...and mobile development in general) and I've gathered that 'exists?' has been deprecated as of certain versions of ruby (I'm on 3.2.0) although, it runs fine on my machine, so I am confused as to what could be missing. I've been using chruby to install ruby, and the only difference there is that I have ruby versions 2.7.5 and 2.7.7 on my machine ... but of course, there are flags that I had to set in order to actually be able to install them on my machine and I don't believe they affect my project since bundle install and pod install works using 3.2.0.
To list out what all I have installed on these machines:
bundler -> 2.4.1
cocoapods -> 1.11.3
ruby -> 3.2.0
node -> 18.13.0
xcode -> 14.2 (with command line tools)
Another bit of error reporting, in case it is useful:
Command `pod install` failed.
└─ Cause: Failed to load 'hermes-engine' podspec:
[!] Invalid `hermes-engine.podspec` file: undefined method `exists?' for File:Class.
# from /Users/<user>/projects/<app_dir>/node_modules/react-native/sdks/hermes-engine/hermes-engine.podspec:46
# -------------------------------------------
# source[:http] = "file://#{destination_path}"
> elsif File.exists?(hermestag_file) && isInCI
# Pod::UI.puts '[Hermes] Detected that you are on a React Native release branch, building Hermes from source but fetched from tag...'.yellow if Object.const_defined?("Pod::UI")
# -------------------------------------------
If there is any information that I need to include for clarity, I will update this post as need-be.
I've tried removing the Pods file, and then pod install... same error
Removed Podfile.lock, cache clean AND removing Pods... same error
Removing node_modules/ npm cache clean --force && npm install
then doing npx pod-install to hopefully let node handle things... same error
Ran pod deintegrate and pod install... was scary, broke things, so reverted, back to square 1
There are other things that I've tried earlier today that I cannot remember, and they've gone home, so I can't access all the commands I ran, but these were the freshest, and until I get a more clear view, I'll be trying to get those flags that need to be set to install the older versions of ruby to see if that does anything
One last mention though, we also recently got an M1 Mac Mini, and I ran through all of the steps to get the project working...ended up in the same rut as the other M1, but again, will be trying those LD_FLAGS or whatever it may be and update this thread if that is what fixes the issue
Looking at older issues related to these, people found work-arounds using -x86_64 commands, and I've managed to get this far without any since maintainers have released newer versions with arm64 support, but if I need it anywhere, so be it, I'll take what I can get at this point
Without needing to install other versions of ruby or anything, I got it install the hermes-engine pod by doing something I find dirty...which is just go into that file it mentions and remove the 's' in exists? so it just says exist? and then I also downgraded cocoapods from 1.11.3 to 1.11.2 and seeing how that .podspec file is laid out, it conditionally loads the engine by first seeing if is downloaded on the machine, and then once it sees that it is not, that's where it eventually hits this problem code with the exists conditional...so it downloaded everything and worked fine and I was able to build and run my app on the mac mini...but when trying the same steps on the other m1 machine, I got a very useful error -- Oh no, an error occured ...perfect, and now I am questioning if these changes I have made will effect the M2 pod commands
If there is no better answer provided in the next few days, I'll assume this is the best possible fix until react-native upgrades their ruby version to 3.2.0 which after some more digging...is the exact release that this exists? file method was removed
But would still love feedback for anyone else using an M1 MacBook who has had these issues on the stable release of React-Native 0.71.0
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 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.
I have been using npm for a personal project and just recently stumbled across yarn. Would there be any harm or "intended side effects" to switching to yarn's package manager in the same project where I had been using npm?
Although a few commenters here say its ok to mix both yarn and npm on the same project, after using yarn and npm and then yarn again, this is what yarn has to say about it:
warning package-lock.json found. Your project contains lock files generated by tools
other than Yarn. It is advised not to mix package managers in order to avoid resolution
inconsistencies caused by unsynchronized lock files. To clear this warning, remove
package-lock.json.
Since to me it is not any harm to using both them into one project.
I use npm and yarn (50/50) in dev environment.
But on ci/di i use only yarn because it is faster, and i reduce build minutes thanks yarn.
Also they both create different .lock file names.
Nobody told about the lock files.
Imagine you use yarn on dev environment, and yarn on your build/production servers. When you install a package using yarn, and your project works on your computer, you probably would want to keep it working on a production environment (your server).
That being sad, you would commit you yarn.lock file, that "saves" the exact versions of each package you have, when the project ran on your computer.
On your buid/production server you should call yarn install, but asking to keep all the same versions with --frozen-lockfile parameter. Some even say "yarn install --frozen-lockfile should be the default behavior", and I agree.
Then... another dev jump in the project you are working and install a package using npm (other than yarn). That new package will not be included in your yarn.lock file, but, a new package-json.lock file would be created, telling the exact packages versions it is using.
When that commit arrives on your build/production server, it will crash, fail, because that new package doesn't exist on yarn.lock file. Someone would need to pull that changes, call a yarn to install the dependences and update the lock file with the new package dependences, and push it again to the repo.
A quick point about using the lock file or not. If you call a 'yarn install' on your build/production server some weeks after the last install on your machine, the server would have many other new versions than your last "stable" version. It already happened to me many times.
I published recently the package-locks-checks, which help ensure you have not just one lock file but also locked each package version on your project.
There will be a point that one or both will no longer work and your project will be stuck at only using the existing lock file. Meaning, the issue probably will involve installation fails if you opt to reinstall without a lock file. And that also means failure to create a new lock file, so you are stuck with the existing one that you are trying to get rid off in the first place. We are actually encountering this issue in one of our projects. Because it is so big, no one tries to fix the issue and just rely on the existing lock file.
So, even if we say it's a rare case that it won't cause harm. Mixing npm and yarn should be avoided.
Here https://classic.yarnpkg.com/en/docs/migrating-from-npm/ we may find a confirmation that Yarn's resolution algorithm is compatible with NPM resolution algorithm.
Inside a npm project (with package.json) if you run yarn it will read your node_modules folder (using the resolution algorithm) and create a yarn.lock file with your project's locked dependency tree.
Based on that I assume that they are compatible inside the same project.
Update 30/04/2021
My original reply refers to yarn 1 (classic), although I've just created a React app with create-react-app tool and it creates the project's repository with package.json + yarn.lock by default. Again, another demonstration that it's fine (even with the warning mentioned by Dave Pile).
At the end of the day this is a matter of putting both together to work and checking yourself...
Plus you get a warning from yarn as Dave Pile said because we have to push *-lock.json files changes you have to consider using npm version >= 7 to make sure whenever you install packages by npm it will update your yarn-lock.json file too.
Because whenever you install the packages either by npm or yarn depends on what you have chosen for updating a dependency in the package.json (Using tilde ( ~ ) which gives you bug fix releases and caret ( ^ ) gives you backward-compatible new functionality) it will update you.lock file and since you have to push it might happen that you have different version of lock files.
I've got these plug-ins in my project
babel-traverse
babel-types
babylon
How do I update these to the latest?
Including typescript plugin.
In my node_modules folder - i've got a bunch of entries that I did not install
adm-zip
inflight
minimatch
lazy
mkdirp
and others - anyone how how it got there?
Running npm outdated shows outdated packages. npm update updates packages. And you need to check the versions listed in package.json to see if they're locked at specific version or if you allow minor/major bumps when running install. There are hundreds of tutorials on using npm and understanding the package.json. those packages you mention, I wouldn't mess with too much. those are added by nativescript to make things work in a sense. So they're dependencies for nativescript they don't actually get packaged with your app (I don't believe, haven't checked that in a build to be certain).