I am developing two npm packages, say #ffx/alpha and #ffx/beta. Beta package is dependant on Alpha package.
alpha/package.json
{
"name": "#ffx/alpha",
"version": "1.0.0",
"dependencies": {},
"devDependencies": {
"some-package": "1.0.0"
}
}
beta/package.json
{
"name": "#ffx/alpha",
"version": "1.0.0",
"peerDependencies": {
"#ffx/alpha": "^1.0.0"
},
"devDependencies": {
"some-package": "1.0.0"
}
}
For local testing, I am building the Alpha project and install built code using following command inside the Beta project root,
npm install ../alpha/dist/#ffx/alpha
Also, I start building Alpha project in watch mode so that code changes in Alpha project reflect in Beta project (inside node_modules) immediately.
My issue is that, in some scenarios where I use the same dependancy in both Alpha and Beta project (some-package in above setup) Beta project get wrong reference of the same package and throw an error.
Example:
Say Alpha project has following code,
...
let smpkg = new SomePackage();
...
In Beta project, it will throw an error saying types missmatch.
error TS2322: Type 'import("~/alpha/node_modules/some-package").SomePackage' is not assignable to type 'import("~/beta/node_modules/some-package").SomePackage'.
Is there a way to align both references using this method?
Or is there a alternative way to use packages locally before publishing?
NOTE: I've already tried npm link and npm pack with mixed results.
I ran into a similar issue. This is how I managed to fix (I'll use your alpha/beta terminology):
Delete node_modules folders from both alpha and beta
Ensure any matching libraries in the package.json files for both alpha and beta match exactly. (For example, some-package should use 1.x.x instead ^1.x.x)
Run npm install on alpha
Ensure package.json for beta is pointed to local module (For example, #ffx/alpha: file:../alpha/dist/#ffx/alpha)
Run npm install on beta
This ended fixing everything for me.
Related
I used the variables in the title of this topics, but I also have the live example.
The alpha version 1.5.0-alpha.0 of the package #yamato-daiwa/es-extensions-localization-japanese depends on version 1.5.1 of #yamato-daiwa/es-extensions:
{
"name": "#yamato-daiwa/es-extensions-localization-japanese",
"version": "1.5.0-alpha.0",
"dependencies": {
"#yamato-daiwa/es-extensions": "1.5.1"
},
"peerDependencies": {
"#yamato-daiwa/es-extensions": ">=1.5.0 <1.6.0"
},
// ...
}
If to install the correct versions of both packages, both distributables will be put directly below node_modules/#yamato-daiwa:
{
"private": true,
"dependencies": {
"#yamato-daiwa/es-extensions": "1.5.1",
"#yamato-daiwa/es-extensions-localization-japanese": "1.5.0-alpha.0"
}
}
Now let's assume that I made a mistake and installed the version 1.5.0 of #yamato-daiwa/es-extensions. In this case, the additional instance of #yamato-daiwa/es-extensions will be put below node_modules/#yamato-daiwa/es-extensions-localization-japanese/node_modules.
The localization will be applied anymore, but there also will be any error, so if it was not the experiment, I could not undestrand the cause.
How to make use install the appropriate version of #yamato-daiwa/es-extensions? Is more strict peerDependencies like "#yamato-daiwa/es-extensions": "1.5.1" will be enough?
As you noted - you have 2 installations #yamato-daiwa/es-extensions - in main app's node_modules and in #yamato-daiwa/es-extensions-localization-japanese node_modules. Your application uses the package from its node_modules folder, but the localization uses another instance from its node_modules. That's why localization is not working.
To prevent this, you should enable strict-peer-deps property in the project's .npmrc file. npm will treat non-compatible peer dependencies as a failure.
I have a huge project, which I was will simplify for the issue, with 2 workspaces.
The main packages looks like
workspaces: [ 'workspace-A', 'workspace-B' ]
My workspace-A has a dependency to external package (here, jest), in a needed version
name: "workspace-A",
dependencies: {
"jest": "<27.0.0"
}
My workspace-B has a dependency to the same package, but doesn't care about its version.
name: "workspace-B"
dependencies: {
"jest": "*"
}
After a yarn install (with yarn v3), I was expecting yarn to automatically install jest with a 26.x.x version in my main node_modules.
Instead, the node_modules of the main project contains jest 26.x.x, and the node_modules of the workspace-B contains jest 27.x.x. It's OK for my, even if I find this weird, but the thing is the workspace-A now uses jest 27.x.x!
I succeeded make it work by adding a resolution field in the main package file, but it's not ideal, as this package doesn't need jest.
"resolutions": {
"jest": "^26.6.3",
}
My 2 questions are
Why is yarn installing 2 versions of jest, is there a way to prevent this?
Is there a configuration somewhere I should put to specify to the workspace-A to not use something from workspace-B?
Thanks for reading
I am trying to deploy a function to Google Cloud Functions. I based it on their ImageMagick tutorial.
Every time, the function fails to deploy because it reaches an error. Looking at the log, the error is:
Provided module can't be loaded.
Did you list all required modules in the package.json dependencies?
Detailed stack trace:
Error: Cannot find module 'sharp'
I can't figure out why this is happening, because sharp is in my package.json dependencies. If I open the web editor for the function in the Google Cloud console, the package.json is there as one of the files and shows sharp as a dependency. I tried running npm install and npm install --save and re-deploying, and that hasn't fixed anything.
I'm including the package in the function with const sharp = require('sharp'); (this is the line where the log shows the error occurring), and this is my package.json:
{
"name": "Resize images",
"version": "0.0.1",
"private": true,
"author": "James Tyner",
"engines": {
"node": ">=10.0.0"
},
"dependencies": {
"#google-cloud/storage": "^5.0.0",
"sharp": "^0.25.4"
}
}
Can you help me figure out what I'm doing wrong?
This has happened to me many times since I was tricked to install packages in the project directory. It works fine locally but creates an error when you try to deploy.
It worked for me when I changed directory into the functions folder, instead of the firebase project folder and did a package install in there
cd functions
npm install [your missing package] --save
I was running into this issue. Various dependencies were causing my function deployment to fail. After a bit of digging I found that the peer-dependencies were not being included.
Adding this fixed my issue
"scripts": {
...
"gcp-build": "npm i npm-install-peers"
},
checking the docs.
the gcp-build command allows us to perform a custom build step during the function build process.
Somehow I was able to address the issue, but I don't fully understand what I did differently. I found that the dependencies listed in package.json weren't being installed when I ran npm install, so I created a separate folder and copied my code there, ran npm install in the new folder, and it worked well from there. Since then, the dependencies have been working properly when I change them and re-deploy the function.
Using Node v12.13.1 and serverless deployment with webpack to GCP and cloud-functions, I've struggled with this issue. In my case it was a different module though. The problem is that no module from node_modules will be possible to require or import. The reason becomes clear if one takes a look at the webpack zip-file in directory .serverless. It seems that with GCP nothing but the file (typically index.js) denoted as "main" in package.json is actually included.
The solution was to adapt webpack.config.js to explicitly include those files missing.
webpack.config.js
I am publishing a npm package developed with Browserify, and wonder what is the proper manner to construct a package.json.
The package is a node server-client app (it is actually atom package), and the client side is based on Browseriy.
./www/js/index.js -> ./www/js/index.bundled.js
The required modules are marked and highlight.js.
The both modules are used only on the client side code/file which is bundled by blowserfiy.
A lazy and simple solution would be simply, just to have
package.json A
{
......,
"dependencies":
{
...,
...,
"highlight.js": "*",
"marked": "*"
}
}
and to include the www/js/index.bundled.js file in the npm package files as it is after the browserify in my local dev environment.
However, now I think the npm package.json can be one of the below:
package.json B
{
......,
"dependencies":
{
...,
...,
},
"devDependencies":
{
"highlight.js": "*",
"marked": "*",
"browserify": "*"
}
}
In this case, browserified ./www/js/index.bundled.js file is left in the npm package, and treat marked and highlight.js as a devDependencies, and also browserify.
Then
package.json C
{
......,
"dependencies":
{
...,
...,
"highlight.js": "*",
"marked": "*",
"browserify": "*"
},
"scripts": {
"run": "browserify ./www/js/index.js -o ./www/js/index.bundled.js"
}
}
Just let you know, I have never tried this, and don't know this scripts-run actually runs on npm install myPackage, perhaps not, and maybe you know the proper configuration, maybe there's no such a thing.
In this scenario, ./www/js/index.bundled.js is excluded from the npm package file, and built from the latest npm packaged marked and highlight.js.
The reason I think this manner is somewhat proper is especially in the scenario the npm modules are used and shared in both server and client side.
For instance, take a look at dnode. This RPC module is developed by the same author of browserify (#substack), and should share the same version of dnode module in both server and client side. If a pre browserified ./www/js/index.bundled.js is bundled in the published npm package, it will be outdated compared to server side dnode. Sure we may be able to specify the version to install by package.json, but it's better to use the latest on both server and client side.
Any suggestion? Thanks.
I suggest to use second choice and specify browserify as a devDependency.
You have to build it before you publish your package to npm registry, so users won't need to install browserify themselves.
It's also useful to add a Makefile and make as a prepublish script.
When I remove the devDependencies array, trimArguments installs fine. If I give it a dev-dependency, it seems to completely ignore trimArguments. No warning, just silent failure. My package.json is the following:
{"name":"asyncFuture",
"version":"0.1.0",
"main": "asyncFuture.js",
"dependencies":[
"git+https://git#github.com/fresheneesz/trimArguments.git#578afe0fa6ce96797c36e018bf5bae31b508a02f"
],
"devDependencies": [
"git+https://git#github.com/fresheneesz/deadunit.git#8395e438492267b94ef51ee4f94a6d6c8f1c15da"
],
"repository": {
"type": "git",
"url": "git://github.com/fresheneesz/asyncFuture"
}
}
Is this an NPM bug or am I misunderstanding how to use this? NPM version 1.3.8 on windows 7 32-bit
UPDATE
It's looking like npm is ignoring any package except for the last one, even if I put all dependencies under the "dependencies" array (and get rid of devDependencies). This has to be a bug. I'm gonna file a ticket.
When using URLs as dependencies:
You may specify a [...] URL in place of a version range.
Noting that dependencies are:
specified with a simple hash of package name to version range.
You still need to specify the package name even when using a (Git) URL.
"dependencies": {
"trimArguments": "git+https://git#github.com/fresheneesz/trimArguments.git#578afe0fa6ce96797c36e018bf5bae31b508a02f"
},
"devDependencies": {
"deadunit": "git+https://git#github.com/fresheneesz/deadunit.git#8395e438492267b94ef51ee4f94a6d6c8f1c15da"
}
dependencies and devDependencies are not arrays; they are maps.
https://npmjs.org/doc/json.html#dependencies