How to integrate other ember app to existing project? - node.js

I am working on ember cli version 1.12 and node js version v0.12.7,I want to intergrate ember-cli-barcode addon.I have tried following:
ember install:npm ember-cli-barcode
Then it will show message that it required node version 4 >.So I have used Node version v7.0.0 stable.I installed node modules and addon.
Then tried following command:
npm install
bower install
ember server
But It will always shows errors,of node-modules etc.Kindly help me for the same how to integrate addon and which file need to change.

This should be a comment but I can't comment yet. I'm the author and it's compatible with Ember 2.4 onward. I will be putting version compatibility information in the readme.
I haven't worked with a cli version this old but ember install should be all you need if it's compatible. The add-on is a really thin wrapper around JsBarcode, so you could use the library direct if you have stay with the current ember version.

To get the benefits of the full ember-cli ecosystem, you'd have to be using the versions that support it. I think that it began in 1.13
As mentioned, it's highly likely that this addon assumes the standard CLI setup. You could ask the author.
Depending on your app complexity, you could do a few different things.
You could use the js library https://github.com/lindell/JsBarcode - (which is what the addon uses)
OR you may want to rewrite the app with the latest and greatest - now. 1.12 is going to be expensive to keep up / and since you've likely figured out how all the logic should work, then writing it again won't be the hardest part. (this sounds fun, right?) - and then use the addon
Which will take longer?

Related

Compatibility issues Node and Strapi4

allow me to walk you through some problems I'm encountering when setting up Gatsby with Strapi. Hopefully, somebody can provide me with a solution. Whenever I use the following command yarn create strapi-starter strapi-test gatsby-blog I get the following error:
So what I do next is switching to node v15 using nvm to make strapi compatible with node. The result being that some packages are being installed followed by yet another compatibility error:
Therefore, I am wondering what I am doing wrong and how to make strapi4 compatible with node without having the errors above?
Use Node.js v16 rather than v15. It should fix the issue.
Besides, it's better to use even-numbered version of Node.js, as they're LTS.

Publish different builds of a npm package to target different versions of node

I'm have a small npm package which I'm writing in node 9 and using all the latest and greatest features like async/await. I'm also using babel which allows me to use ES6 module imports and exports
Babel also allows me to transpile the package to a target node version. I'm using the node release schedule to define which version of node the package will support and with the the target for the babel compilation. Currently node 4.x is still in maintenance lts stage, so I'm targeting it. Unfortunately this means almost every new feature in JavaScript I'm using gets transpiled.
What I'd like to do is to transpile the package to different targets (4.x, 6.x, 7.x, 8.x, and 9.x currently apply) and have npm choose the appropriate build of the package at install time based on the user's node version. If I'm not mistaken, I've seen apt-get do this with different versions of Ubuntu.
Is this possible with npm?
I'll bump an old thread here. A good option is to use two separate directories and choose the transpiled version depending on process.version.
I'll be trying to do this in scramjet and will be updating the thread along the way. My plan is to use an index.js file like this:
const ver = process.version.slice(1).split('.');
module.exports = require(+ver[0] > 8 && +ver[1] > 3 ? 'lib/index' : 'lib-6/index')
This should do for now, but since I also have some v10+ targeted code (especially DataStream.from(async function*() { ... }) which has some ifs in it I may want to extend it later and use a table.
What's important here is that the code above runs once (unless you clear require cache) and mostly in compile time so it has minimal influence over your module.

"no template named 'WeakCallbackData' in namespace 'v8'" error when installing npm packages

Some packages that depend on https://www.npmjs.com/package/fibers fail to install with error message above. Particularly it is iron-meteor.
Homepage of the fibers states:
meteor users please read this
If you're trying to get meteor running and you ended up at this page you're probably doing something wrong. Please uninstall all versions of NodeJS and Meteor, then start over. See meteor#5124 for more information."
But it does not seem to be very helpful.
One guy recommends to downgrade node.js here https://github.com/NativeScript/NativeScript/issues/2991
It helps indeed, but it is kind of hack, right?
Node version affected: v7.2.0
Node v6.9.2 works well.
WeakCallbackData was removed from the V8 API earlier this year. Since this change has landed in Node 7, packages that rely on v8::WeakCallbackData don't work anymore. You need to downgrade Node or wait until Meteor supports Node 7, i.e., uses a newer node-fibers version.

Error after packaging the app with electron-packager

I'm new to Electron, and I really love it so far, but I'm unable to package any of mine apps, at first I thought that it's maybe something related to my code, then I download "https://github.com/atom/electron-quick-start" run npm install and then I run "electron-packager . FooBar --platform=darwin --arch=x64 --version=0.28.2" it build the app but when I try to open it I get
so I didn't touch any code from the example, just wanted to build it and I got an error, what am I doing wrong? Thanks!
The versions of electron are moving very very fast.
And some times, they don't respect the "old" ways to do things (for example, declaring the app).
I advise you to not use the 0.28.2 version of electron but the most recent one.
It is very likely that the version of electron-prebuilt you are using to develop is much much much more recent than the 0.28.2 version. So, you are developing with something much newer, and then you are building with 0.28.2. This would cause the exact error that you are seeing, as older versions may not have had the electron module, which your code explicitly is importing. So... that is my suggestion. Change the version in your electron-packager command from 0.28.2 to something like 0.36.0. See if that works. Or better yet, use the same version as electron-prebuilt in your package.json.
This could be a combination of factors.
First, as others stated, the version of electron that you have might be newer than the one referenced in your build command. Locate the 'electron_prebuilt' folder inside your 'node_modules' folder, and examine the package.json file and make sure the version # is the same as what you are declaring in your build command.
If they are the same, then the issue might be that you have another version of electron on your computer that node is trying to use. If you installed electron via the -g option (global), check your home folder to see if there is another different version of electron. If you find one, either delete it or rename the 'electron_prebuilt' folder you find to something else. Try your build command again, and it should work now that you've eliminated the other versions of electron_prebuilt on your computer that node was referencing.
What worked for me was to move the "electron" module from "dev-dependencies" to "dependencies" in package.json. Try this and see if it works.

Nodejs (Sync) cannot find fibers binaries

I've seen similar questions but no real solution that worked for me yet (most users just reinstall fibers or meteor (I'm not using meteor)).
I've added the nodejs module Sync to my nodejs 0.12.6 project. It's dependency is the Fibers module that got installed automatically with Sync. Now I wanted to load Sync via require, but it fails with the message
... /win32-x64-v8-4.3/fibers.node not found
And it's correct: In sync/node_modules/fibers/bin/ is no directory named win32-x64-v8-4.3, only win32-x64-v8-4.2 and renaming didn't solve the problem (would have been too easy)... 🙈
How can I solve this problem? How can this happen?
What is the meaning of the last number (4.3)? I guess it's windows, 64bit, Javascript v8 engine, and then? Fibers version?
Any ideas or hints?
Update:
I tried to updgrade node to 0.12.6, but nothing changed.
I found out what the 4.3 is about, it's the v8 version. Well, when running my application with electron, it is v8: '4.3.61.21'. When checking the version with node, it is 3.28. So it's maybe electrons "fault"?
Update #2:
Okay i found out that electron is based on io.js and not node. That explains the different v8 versions. But still no solution. When installing fibers with latest io.js (2.3.3), it tests the 4.2 binary, but electron requires 4.3 :(
Update #3:
Even with the same io.js version 2.3.1 as electron, it does only install the 4.2 binary.
Update #4:
Now, I've tried all three ways described at http://electron.atom.io/docs/v0.27.0/tutorial/using-native-node-modules/ (with electron version 0.29.1) - still no solution. There aren't any binaries for v8-4.3, still only the v8-4.2 ones. :(
Solution:
See my answer below. :)
At the end, i had to compile fibers on my own. As described in Update #4, i've tried it before. But node-gyp always failed and i didn't notice that i have to link to the new binary file on my own...
cd ~/my-project-root/
npm install sync
cd ./node_modules/sync/node_modules/fibers
node-gyp configure
HOME=~/.electron-gyp node-gyp rebuild --target=0.29.1 --arch=x64 --dist-url=https://atom.io/download/atom-shell
Then i've created the missing directory and moved the new binary there:
mkdir bin/win32-x64-v8-4.3
mv build/Release/fibers.node bin/win32-x64-v8-4.3/fibers.node
Now Sync works like a charm.
You need to use the electron-rebuild tool to rebuild your native module against the version of Electron you're using

Resources