Currently all images in my react project are being served by the nginx server. These images are bundles with source. The source does not use require/import but instead uses url paths to render the images.
Now I want to serve these images from cloudfront, using S3 as my storage.
I plan to create a set of assets on S3 for every environment.
I can think of two approaches for doing this:
Approach 1. Using a script
create a script that runs after webpack bundling
the script will upload files to S3
paths in script and source will be deduced based on env variables
Approach 2. Create a webpack loader
update source to import/require images
create a loader that upload images to S3 and returns public path
Any opinions on these approaches or suggestions on a better approach ?
I ended up creating a webpack plugin that uploaded my static assets to S3.
I used a build parameter to deduce the base path of static assets in source and same param for deducing the upload path in plugin.
Related
I am trying to deploy a next js application to s3 bucket with dynamic routes and ISR implemented . I'm using some locally stored images from assets folder in public . But after deploying it to S3 , it's returning 404 for the images even after the build folder has all the image files . Can anyone help me with this issue ?
I have a website built with a Strapi/Nuxt stack.
I can make it totally static, instead of pre-rendering pages, but I still need to retrieve the images or other assets from Strapi, so I still do need a server.
During the "compilation", the Strapi API is fetched and the contents used to pre-render all the pages I want: would be possible to also download all the assets into the dist directory during the nuxt generate operation?
During the build, you can query Strapi's API and get the assets URL, nothing blocking you here.
Otherwise, you could also download the file itself and write it down into your project.
Here is one my answer that you can get some ideas from: How to access remote data and write it into a file during Nuxt build?
It's not Webpack's job to do this neither. As a pre-build tool, I guess that you can use nodejs-file-downloader and use it at the top of your nuxt.config.js file.
This one looks great and is active: https://github.com/hgouveia/node-downloader-helper
I am a bit new to Vue.js. I am doing a social media application that allows users to upload and share images with others. I store my images in src/assets folder during development. However, when I build the project, all images are put in the dist folder. Therefore, what can I do to enable users to still upload images on production? Do I create the assets directory in the dist folder?
I have since tried different ways, including storing images on the backend. In dooing this, I reference the backend path relatively, using, for example, ../../../backend/public/assets..., and it works on development. However, when I build, the images that existed in the backend directory at the time of building are visible, however, whenever I try uploading more on production to the ../../../backend/public/assets... directory, they are uploaded successfully but are not visible (that is on production). I get an error that Cannot find module './image_name.image_extension'.
What am I doing wrong?
I have seen similar questions like this but there was no answer.
You must set your public path and change your way!!
first step to do is creating vue.config.js in your root directory, if you want to know more details, read this: https://cli.vuejs.org/config/
for example, I define prefix path for my files:
module.exports = {
publicPath:
process.env.NODE_ENV === "production" ? "/" : "/",
};
remember, It's better if you use "#" to define your paths.
for example, if you want to load a image which located in src/assets/files/img/myImage.png, you can use #/assets/files/img/myImage.png in template section for binding or script section of your .vue files!
It always help you to find correct path of your files.
and finally your way is not standard because "src/assets/..." will used for compiled scripts and styles and also your files which you want to use on your UI layout like static images. so you have to use "public/assets/..." directory to save your file, then you will see everything is going well for you.
if you have a more question or stuck solving this problem again, I'm here to fix your issues.
I have an express container that serves static files and it works perfectly when built and deployed locally. However, when I build and deploy it to Cloud Run, the dynamic html is returned but static assets like css files are 404. Are there any known limitations with Cloud Runthat May be contributing to this difficult-to-diagnose issue?
Searching the problem, I found this issue and realize the correct answer is masked because it's in the last comment on SO.
Google cloud use a file called .gcloudignore to not ignore some files while uploading.
If the file does not exist, .git and .gitignore files are used, and typically some assets will be in your .gitignore.
https://cloud.google.com/sdk/gcloud/reference/topic/gcloudignore
I have a Vue CLI application that I'm currently working on that uses code splitting for JS and CSS, and builds almost 1,000 JS/CSS files on running npm run build.
I am hosting this application on Google Cloud Run, where I pay per request. While the cost is still not that significant, I was still looking to try and prevent the need for 500 requests for every page view. I had a thought, but I'm not sure it's possible...
What I was wondering was if I could have my webpack build generate the JS and CSS files into the dist folder, but reference those files in the index.html file with an external host, instead of assuming a relative path. For instance, the file would exist at dist/css/chunk-abc123.js but in index.html, it would be something like https://storage.google.../css/chunk-abc123.js.
That way, in my CI pipeline, I can upload those files from the dist directory into Google Cloud Storage, and serve them up statically from there.
Does anyone know if this is possible? If so, can you guide me in the right direction?
publicPath comes in rescue.
The base URL your application bundle will be deployed at (known as
baseUrl before Vue CLI 3.3). This is the equivalent of webpack's
output.publicPath, but Vue CLI also needs this value for other
purposes, so you should always use publicPath instead of modifying
webpack output.publicPath.
// vue.config.js
module.exports = {
...
publicPath: 'https://storage.google...'
...
}