Gathering detailed insights and metrics for gatsby-plugin-remote-images-d0m3
Gathering detailed insights and metrics for gatsby-plugin-remote-images-d0m3
Gathering detailed insights and metrics for gatsby-plugin-remote-images-d0m3
Gathering detailed insights and metrics for gatsby-plugin-remote-images-d0m3
💾 A Gatsby.js plugin for downloading and linking remote images from another node's field for the benefits of gatsby-image.
npm install gatsby-plugin-remote-images-d0m3
Typescript
Module System
Node Version
NPM Version
17.2
Supply Chain
51.8
Quality
62.1
Maintenance
25
Vulnerability
90.9
License
JavaScript (100%)
Total Downloads
0
Last Day
0
Last Week
0
Last Month
0
Last Year
0
156 Stars
182 Commits
39 Forks
2 Watchers
30 Branches
19 Contributors
Updated on May 26, 2025
Latest Version
2.2.3
Package Id
gatsby-plugin-remote-images-d0m3@2.2.3
Unpacked Size
17.28 kB
Size
5.07 kB
File Count
3
NPM Version
6.13.4
Node Version
12.16.1
Cumulative downloads
Total Downloads
Last Day
0%
NaN
Compared to previous day
Last Week
0%
NaN
Compared to previous week
Last Month
0%
NaN
Compared to previous month
Last Year
0%
NaN
Compared to previous year
2
1
Download images from any string field on another node so that those images can
be queried with gatsby-image
.
First, install the plugin.
npm install --save gatsby-plugin-remote-images
Second, set up the gatsby-config.js
with the plugin. The most common config
would be this:
1module.exports = { 2 plugins: [ 3 { 4 resolve: `gatsby-plugin-remote-images`, 5 options: { 6 nodeType: 'myNodes', 7 imagePath: 'path.to.image', 8 }, 9 }, 10 ], 11};
However, you may need more optional config, which is documented here.
1module.exports = { 2 plugins: [ 3 { 4 resolve: `gatsby-plugin-remote-images`, 5 options: { 6 // The node type that has the images you want to grab. 7 // This is generally the camelcased version of the word 8 // after the 'all' in GraphQL ie. allMyImages type is myImages 9 nodeType: 'myNodes', 10 // For simple object traversal, this is the string path to the image you 11 // want to use, relative to the node. 12 // This uses lodash .get, see [docs for accepted formats here](https://lodash.com/docs/4.17.11#get). 13 // For traversing objects with arrays at given depths, see [how to handle arrays below](#traversing-objects-with-arrays) 14 imagePath: 'path.to.image', 15 // ** ALL OPTIONAL BELOW HERE: ** 16 // Name you want to give new image field on the node. 17 // Defaults to 'localImage'. 18 name: 'theNewImageField', 19 // Adds htaccess authentication to the download request if passed in. 20 auth: { htaccess_user: `USER`, htaccess_pass: `PASSWORD` }, 21 // Sets the file extension. Useful for APIs that separate the image file path 22 // from its extension. Or for changing the extention. Defaults to existing 23 // file extension. 24 ext: '.jpg', 25 // Allows modification of the URL per image if needed. Expects a function 26 // taking the original URL as a parameter and returning the desired URL. 27 prepareUrl: url => (url.startsWith('//') ? `https:${url}` : url), 28 }, 29 }, 30 ], 31};
Why do you need this plugin? The fantastic gatsby-image tool only works on relative paths. This lets you use it on images from an API with an absolute path. For example, look at these two response from one GraphQL query:
Query
1allMyNodes { 2 edges { 3 node { 4 id 5 imageUrl 6 } 7 } 8 }
Absolute imageUrl NOT available to gatsby-image
1allMyNodes: [ 2 { 3 node: { 4 id: 123, 5 imageUrl: 'http://remoteimage.com/url.jpg', 6 }, 7 }, 8];
Relative imageUrl IS available to gatsby-image
1allMyNodes: [ 2 { 3 node: { 4 id: 123, 5 imageUrl: 'localImages/url.jpg', 6 }, 7 }, 8];
If you don't control the API that you are hitting (many third party APIs return a field with a string to an absolute path for an image), this means those image aren't run through gatsby-image and you lose all of the benefits.
To get the images and make them available for the above example, follow the install instructions and your config should look like this:
1module.exports = { 2 plugins: [ 3 { 4 resolve: `gatsby-plugin-remote-images`, 5 options: { 6 nodeType: 'myNodes', 7 imagePath: 'imageUrl', 8 // OPTIONAL: Name you want to give new image field on the node. 9 // Defaults to 'localImage'. 10 name: 'allItemImages', 11 }, 12 }, 13 ], 14};
Now, if we query allMyNodes
we can query as we would any gatsby-image node:
1allMyNodes { 2 edges { 3 node { 4 localImage { 5 childImageSharp { 6 fluid(maxWidth: 400, maxHeight: 250) { 7 ...GatsbyImageSharpFluid 8 } 9 } 10 } 11 } 12 } 13}
gatsby-source-graphql
Due to the way gatsby-source-graphql
creates nodes, it is currently impossible
for any transformer type plugin to traverse the data from that plugin.
Please read this issue for explanation.
As soon as that as fixed in gatsby-source-graphql
, this plugin will be tested
to make sure it works with it as well.
Since some GraphQL APIs will send back objects with nested arrays where your
target data lives, gatsby-plugin-remote-images
also supports traversing
objects that have arrays at arbitrary depths. To opt in to this feature, add an
array literal, []
, to the end of the node you want to indicate is an array.
Given an object structure like this:
1allMyNodes { 2 nodes: [ 3 { 4 imageUrl: 'https://...' 5 }, 6 ... 7 ] 8}
To get the images and make them available for the above example, your config should look like this:
1module.exports = { 2 plugins: [ 3 { 4 resolve: `gatsby-plugin-remote-images`, 5 options: { 6 nodeType: 'myNodes', 7 imagePath: 'nodes[].imageUrl', 8 }, 9 }, 10 ], 11};
Now, if we query allMyNodes
we can query as we would any gatsby-image node:
1allMyNodes { 2 nodes { 3 localImage { 4 childImageSharp { 5 fluid(maxWidth: 400, maxHeight: 250) { 6 ...GatsbyImageSharpFluid 7 } 8 } 9 } 10 } 11}
lodash .get
doesn't natively support this syntax, it is still used to traverse the object structure, so the documentation for .get
still applies in full.No vulnerabilities found.
Reason
no binaries found in the repo
Reason
no dangerous workflow patterns detected
Reason
dependency not pinned by hash detected -- score normalized to 3
Details
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
Found 0/12 approved changesets -- score normalized to 0
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
detected GitHub workflow tokens with excessive permissions
Details
Reason
security policy file not detected
Details
Reason
license file not detected
Details
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
41 existing vulnerabilities detected
Details
Score
Last Scanned on 2025-07-07
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More