Okay, I'm trying to publish my Nuxt.js app on my web host but I've run into some issues. I do not want a static site.
After running "npm run build" locally, I transferred the files to my web host with FileZilla. Then I'm supposed to fill in the statements shown in the picture below.
And this is where my problems begin. The app does not want to start at all, and i am nor sure what to put as "Application startup file". And according to my web host, the overall problem is that there is no startup file for Nuxt applications. I am completely new to Nuxt and do not have that knowledge and therefore I now turn to you, is it the case that there is no starup file for Nuxt?
The web host also mentioned that it is more difficult to get a Nuxt application upp and running on shared hosting, is that correct? Will I not be able to get my app up and running in this place?
My web host had received this error message when they tried to start my app. Maybe there are some clues in there to find.
ERROR Request failed with status code 404 15:58:38
at createError ({{my-adress}}/14/lib/node_modules/axios/lib/core/createError.js:16:15)
at settle ({{my-adress}}/14/lib/node_modules/axios/lib/core/settle.js:17:12)
at Unzip.handleStreamEnd ({{my-adress}}/14/lib/node_modules/axios/lib/adapters/http.js:260:11)
at Unzip.emit (events.js:315:20)
at endReadableNT (internal/streams/readable.js:1327:12)
at processTicksAndRejections (internal/process/task_queues.js:80:21)
Hope someone can help!
Without some more context, I can't tell you exactly what your issue is but I suspect it is to do with how the web server on your shared hosting is configured to serve files. When you visit a route, it's not correctly finding that index.html page.
A Nuxt static application deploys with a structure where each page route has its own rendered index.html page inside a folder - if I'm not mistaken.
Your web path may look like example.com/hello but in reality it resolves as example.com/hello/index.html. Some web servers will struggle by default with this structure if not setup correctly.
Honestly, if I were you I'd deploy the project to either Vercel or Netlify.
Both have incredibly generous free tiers that will let you host your application for (if it's not making any money) for a very long time at a good scale.
They both run on automatically scaling infrastructure so you don't need to worry how much resources your site is consuming or how many users you get. It will maintain responsive and reliable without any detriment to load speed.
They'll also automatically handle building and deploying the application on your behalf. All you need to do is connect the service to a Github repository.
They also provide CDN's and other optimisations such as compression for you as well to make your site much faster.
Nuxt has a dedicated page on Netlify deployment. I recommend you give it a read:
https://nuxtjs.org/docs/2.x/deployment/netlify-deployment/
When you do npm run build (or npm run generate), your final content will be available in the /dist directory (the console should tell it to you at the end). It contains an index.html file, this is the one that serves as entry point.
Btw, before going any further double check that this is working locally:
npm run build
npm run start (URL and port will be given to you)
If it works locally, you can proceed.
.nuxt is essentially used for development purposes, caching and so on. And should not be tracked by Git, nor deployed.
I'd like to advice against using FTP for deploys (especially if not secured). Prefer a more modern way, like pushing your latest git commit and let the platform handle the hook or fetching your new code and bundling your app for you.
As recommended above, Netlify is one of the best place to easily host your Nuxt app: simple, fast and headache-free. Also, check #jordan's link about the various platform deployments, you may find yours (if it's good/well known).
I may come here a little late, but this is the way I configure the "Application startup file" when deploying a Nuxt app in shared hosting using the NodeJS Selector app (that commonly you find in CPanel)
Since basically the startup file in NodeSelector is executed as if you would run node startup_file.js, you can create an app.js at the root of the project, and add the following code:
require('#nuxt/cli').run(['start']);
This is basically the same as nuxt start, which is basically the start script in your package.json
Hope this can help others having the same issue. I leave here the same issue posted in git:
https://github.com/nuxt/nuxt.js/issues/7192
Related
I've built multiple sites with Nuxt SSR, but never touched the static part.
As far as I know, upon build-time, Nuxt automatically executes all API calls and caches them.
If I want to make a blog with a static Nuxt site, how would I update the content? Is it only possible when I rebuild the app?
Seems unnecessary to rebuild everything every time I add a new blog post. With SSR I just reload the page.
Also wanted to note that I have a Strapi.js backend running on a VPS and I usually make changes weekly. Nuxt's docs state that I need to push my changes to the main repo branch but there's no changes on the frontend.
Does this also mean that the headless cms should be local only?
The whole point of having a static build is to have all the generated files with no additional server Node.js server needed. It reduces heavily the costs, removes a point of failure, discard any notion of server charge (amount of users at the same time on your app) and probably some other advantages yeah.
Downside, you indeed need to actually yarn generate the whole app again if it's something that was added/changed in the codebase. Usually it's pretty fast and there are also incremental builds if I do remember properly (you will not regenerate all the 99 old blog posts but only the 100th, the new one).
Headless CMS like Strapi usually work with a webhook: you add a new CMS article or alike, Strapi will notify your JAMstack platform to rebuild your app. Even if no front-end code was changed, you can force to build it with the new data coming from the headless CMS' API.
I have a VueJS application that is deployed to a local IIS 10 server for intranet use.
Trouble is, the index.html file is getting cached and a forced, manual clearing of the browser is needed to see updates. I understand there are ways on the server side to prevent this, but I'm unclear based on what I've read so far as to what the proper way of making sure the html file isn't cached is (js, css and the like are, of course, not cached since they have the additional value appended to the file name during build.)
I'm very much a novice when it comes to the server side of things, so any insight would be greatly appreciated. Thanks!
Which packaging tool do you use in your project? Generally speaking, Webpack/Vue-CLI has settings for prevent the file from caching in the browser on the client-side. In other words, it adds hash value to output files which could flag the version we build recently, this will result in the client browser to forcibly request the new version file.
In the Webpack.config.js
output: {
filename: '[name].[contenthash].bundle.js'
}
https://webpack.js.org/guides/caching/
See these links for more details.
Browser cache problems with webpack chunks and vue.js components
how to force clearing cache in chrome when release new Vue app version
VueJS/browser caching production builds
I'm finding the iterative development cycle quite slow on service fabric as opposed to a standalone .NET Core web application. It does not look like browser link works, hell even refreshing the page doesn't update HTML. From what I can see, you need to restart the whole fabric to update HTML changes.
There has to be something I'm missing.
We have this feature in the pipeline. Will be a few months out, but is coming.
To enable quick iterations on static files and other files that do not need build time compilation, the current hack is to start debugging your app or deploy it to the cluster so it's running. Find the files in the cluster node directory (Typically C:\SfDevCluster\Data\_App\_Node_0\....) edit them there and refresh your browser. Remember to copy changes over to your source before stopping debugging or removing the app, as this will delete those files.
Make sure to set you local cluster in one-node mode, to ensure you only have the files being served from one directory.
I'm trying to get information about license info of my app and MSDN docs (http://msdn.microsoft.com/en-us/library/windows/apps/hh694065.aspx) advice to use Windows.ApplicationModel.Store.CurrentAppSimulator class for that purposes during development/testing and when submitting app to store replace that class with Windows.ApplicationModel.Store.CurrentApp.
I wonder if there is any way to check in code (javascript in my case) if app is already installed from store so my code should use proper class and I won't have to remember every time I submit update of app to store to replacing those classes properly.
As far as I know, I could not find such thing. In fact, LicenseInfo is what provides information about the store listing.
I use a config.js file to keep settings at place which change between development and production. For example - if your app talks to a service, service URL also will likely change between development and production; the service might be running at localhost for development and for production in azure environment. I keep a bool in here and change by hand.
I have not automated it fully. but it is likely possible. need to dig through the msbuild logs for the build created for the store. if there is configuration setting found, then project can have two config.dev.js and config.release.js and msbuild need to conditionally pick the right file. I haven't looked into this yet.
I think I found at solution as described here WinJS are there #DEBUG or #RELEASE directives? . Not ideal, but works for me.
Folks:
I'm creating an app using Node Webkit. The purpose of this app is to display images and pdfs. The app needs to download those files from a central repository, and cache them locally. When the app runs offline, the files should still be available, and displayed.
On the face of it, this sounds like appcache is the answer - and that indeed is where I was heading when this was a pure webapp in a browser. However, now I've discovered node-webkit, and here we are.
node-webkit's GitHub wiki states:
"However, application cache is designed for browser use, for apps using node-webkit, it's less useful than the other two method, read HTML5 Application Cache if you want to use it."
But doesn't say why.
I've also researched node.js filesystem - but that seems like a whole magnitude of complexity above what I need.
Can anyone point me in a sensible direction?
Thanks.
It has to do with the nature of App Cache itself.
You specify a manifest file that lists all the static assets required for your app to run offline. You don't have any programmatic access to the cache to add and remove files via JS.
So for a node-webkit app, it'd make more sense to fetch these files and store them in the Application Support folder (Or AppData, depending on the platform). That's where the node.js part is really useful, the file IO stuff.