I'm trying to make a recipe for Noble.
It includes this optional dependency xpc-connection.
I'm using devtool to make the recipe.
I know that recipetool recoginizes that xpc-connection does not support Linux and ignores it. I found a bug in oe-core related to that. Patch here.
However, when I build the recipe, I get this error:
DEBUG: Executing shell function do_install | npm ERR!
...workspace/sources/noble/node_modules/xpc-connection is not a child of
/home/sarah/l/l-alpha/build-l/work/cortexa7hf-neon-vfpv4-oe-linux-
gnueabi/noble/1.9.1+git999-r0/image/usr/lib
I can verify that xpc-connection is not in the SRC_URI for the recipe.
If I try to remove xpc-connection from the node_modules folder, it reappears on build. How can I prevent it from performing this check for the installation of xpc-connection? It shouldn't be a part of the image packages, because it doesn't support Linux.
I solved this by changing the version of node specified by the openembedded layer here - https://github.com/openembedded/meta-openembedded/blob/master/meta-oe/recipes-devtools/nodejs/nodejs_8.9.4.bb.
I changed the file name to nodejs_8.1.0.bb to revert the version. I also modified the checksum in that file for the right node package. I have other issues in the Noble recipe, but this one is solved for now.
Related
I am studying an aplication that has some dependencies. I want to make some changes on one dependency locally.
I tryed to make a symbolic link inside the main application's node_modules direct to the dependency folder, where I have the folders with compiled code (es and lib) using this command ln -s dependency_folder main_app/node_modules/dependecy.
It doesn't work and raises an error:
Error: Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
1. You might have mismatching versions of React and the renderer (such as React DOM)
2. You might be breaking the Rules of Hooks
3. You might have more than one copy of React in the same app
See https://reactjs.org/warnings/invalid-hook-call-warning.html for tips about how to debug and fix this problem.
Is this a right way to develop a dependency package, or I am doing it wrong.
I realize that there is no problem to link to a dependency package. What happened here is that the project source files are out of date. Compiled dependencies are up to date on NPM, on git the sources are outdated.
i will leave this message just for the records.
I want to try and make some changes to a package published in npm? (I've suggest some changes as an issue but I think they are simple enough for me to attempt them).
https://www.npmjs.com/package/bt-presence#contributing--modifying
The author supplies some information on how to modify the package, but not really enough for someone doing it for the first time.
Where should I clone the GitHub repo to? The folder where the package is installed? I tried it in my home folder and that would not build (unmodified).
The command npm run build - where is this run from? The root folder of the package where the package.json is?
Will I need to modify the package.json?
In general what is the best way to develop something like this for npm? I've worked on packages before but they were simply Javascript.
If you want to work on the bt-presence package in isolation, you can put the cloned repository anywhere. If you want to use your modified version of bt-presence in combination with an application, my recommended approach is to register bt-presence as a dependency in the application's package.json file with the version set to a relative path to your bt-presence repository; then running npm install in the application will make a symlink from node_modules/bt-presence in the application to your bt-presence repository.
npm run build should indeed be run from the root folder that contains the package.json of bt-presence.
If you just want to change the code of bt-presence, you won't need to modify its package.json. You would only modify the package.json if you need to change any of the settings in there, e.g, if you need to add additional dependencies to your version of bt-presence.
None of the above is really specific to TypeScript. (Some JavaScript packages have build processes too if they need to transform or package the JavaScript files in some way.)
Let's say there is an npm package called abcd.
Normally in package.json, we specified the dependencies as
"abcd": "^1.0.0",
But this abcd does not work as expected, so I forked (and modified) it inside https://github.com/mygithubid/abcd
Then I run npm install git+https://git#github.com/mygithubid/abcd.git and in package.json, the definition is changed to
"abcd": "git+https://github.com/mygithubid/abcd.git",
After restarting the project that using this abcd, now it throws error
Module not found: Can't resolve 'abcd'
... even though I saw the abcd folder is added inside node_modules
Could you advise the mistake I made in above? Thanks!
One fairly clean option is to use patch-package:
https://www.npmjs.com/package/patch-package
If the people using your project might use either npm or yarn, then remeber to make the patch available for both. More info under patch-package --use-yarn.
Patch or fork? See https://www.npmjs.com/package/patch-package#benefits-of-patching-over-forking
Be sure that the github repository contains compiled files, at most cases you need build the package for npm first, the compiled files push only to NPM.
To find out how to build the package check the package.json file
I'm used to deploy code depending on Composer (PHP's NPM cousing), that sports .json and .lock files. The first one describes the package and your version constraints, and the second one lists exactly what was installed. Always there's a lock file and you run composer install you're sure to receive the same set of packages; running composer update will re-read the json file, install new versions, and update the lock file.
That's awesome for production deployment, since you don't need to checkout your dependencies to your versioning system and you're sure to have the exact same set of dependencies in production as you have in development.
My question is: how to best automate deployment of NPM-dependent code? Is it possible to achieve a method similar to Composer? I've noticed that npm install only installs what's first available in the package.json file. After the first run, i.e. if you change a version constraint you must manually npm update that package - and that would render automate deployment useless, as there's no way to check in to versioning "update this package here to a new version"...
npm shrinkwrap is a analog of composer.lock file. It will generate a npm-shrinkwrap.json, that have all deps with version in it, so you can use it to deploy to production env. Also you can try a various libs from npm to lock versions or search for updates of it without changing packages.json.
I am struggling around a wrong usage of composer, for sure.
I set up this repository: https://github.com/alle/assets-merger
I forked the project and was just trying to make it a kohana-module, including all the dependencies.
As for it would need the YUI comporess JAR, I was trying to make just that JARfile as a dependency, and I ended to declare it in the composer.json file (please, look at this).
Once I need to add my new package to a project I add it in the require section as follows:
...
"alle/assets-merger": "dev-master",
...
But the (latest) composer update command says:
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for alle/assets-merger dev-develop -> satisfiable by alle/assets-merger[dev-develop].
- alle/assets-merger dev-develop requires yui/yuicompressor 2.4.8 -> no matching package found.
Potential causes:
- A typo in the package name
- The package is not available in a stable-enough version according to your minimum-stability setting see <https://groups.google.com/d/topic/composer-dev/_g3ASeIFlrc/discussion> for more details.
And my story ends here.
How should I configure my composer.json in the https://github.com/alle/assets-merger repository, in order to include it as a fully satisfied kohana-module in other projects?
Some things I notice in your composer.json.
There is a version of that CSS minify available on Packagist which says it is just a copy of the original Goole-Code hosted files, but with Composer: natxet/cssmin. It is version 3.0.2, but I think that shouldn't make a difference.
mrclay/minify is included twice in the packages with the same version. It also is available on Packagist. You will probably already use that (version 2.2.0 is registered, and because you didn't turn of Packagist access, it will be generally available for install unless a version requirement or conflict prevents it).
You are trying to download a JAR file (which is a java executable without and PHP), but try to get PHP classmaps out of it. That will fail for sure.
You did miss the big note in the Composer documentation saying that Composer cannot resolve repositories mentioned in sub packages, only in the root package. That means that whatever you mention in your alle/asset-merger package will not be used if you use that package anywhere else. You'd have to duplicate these repositories in every package in addition to adding the package name itself as "required".
What this means is that you probably avoided missing mrclay/minify because it is available on Packagist, you might as well have added the cssmin by accident, but you definitly did not add YUICompressor.
But you shouldn't add this in the first place, because it is no PHP software. You can however add post-install commands to your projects. All your Composer integration does is download the JAR file. You can do that with a post-install or post-update command. See the documentation here.