I made a Vue app with Bootstrap-Vue, Express(nodejs) and MySQL. I'm using vue-cli and It's currently in development mode. I've created a SPA(server and client in different folders), and I'm compiling with vscode terminal using:
cd client
npm run serve
and
cd server
node index.js
My problem is: I don't have a domain because it's only for personal use(and I don't have money), and to open the vscode and doing the rotine takes 20-60 seconds. Is there an alternative and quickly way to run my vue app?
I can think of a couple of things you can do.
1) Get a free domain and free hosting
As I mentioned in the comments, you can get a free domain at freenom.com, and host it for free with render.com. This has some pros and cons to it.
Pros:
It's free.
You can access it from anywhere.
No need to setup every time, just enter the URL.
Cons:
You probably won't get to choose the domain's extention. It'll probably be a .tk domain or something not very well known.
I believe that you need to renew it annually, but that's with any domain.
Anyone an access it, though it's not like everyone will know about it.
Needs an internet connection, but this isn't a problem if your app already needs internet access to function.
You can also host it with Github. Here's instructions on how to do that, and here's instructions to set up Github pages.
See Deploying a Node Express App or Deploying a Vue.js App for instructions on how to set up hosting on render.com
2) Automate what you are doing now
Typing takes time, and you can create a batch file to run those commands for you. Depending on what OS you are on (I'm doing this for windows), you can create a file, e.g. OpenApp.bat and place inside what you are already doing:
cd C://ABSOLUTE_PATH_TO_CLIENT
npm run serve
cd C://ABSOLUTE_PATH_TO_SERVER
node index.js
start localhost:8080 or whatever the path is
Then just double click it and it'll run these tasks for you. I haven't tested this idea yet so not sure if it'll work.
3) Build your app
A third option would be to build your app, then serve it. This would eliminate the time npm run serve takes, and you can host it instead with serve.
Install serve:
npm install -g serve
...and build your app:
npm run build
...and serve the app:
serve -s dist
It should instantly serve your app without any long processing time.
You can create a batch file to do this also (again, I'm not sure if it'll work):
cd C://ABSOLUTE_PATH_TO_CLIENT
serve -s dist
cd C://ABSOLUTE_PATH_TO_SERVER
node index.js
start localhost:5000 or whatever the path is
This should be faster than option 2...but editing your app requires it being re-built each time to see the changes.
Related
(not a native speaker, sorry if things don't seems clear)
We are devs for a clients and we work with others devs from another company. The other devs make us a package that we sometimes change this in it, then submit the changes in a pull request.
So we end up having a local version of the package and the official version. And so we want to use the local version in dev (where we might make little changes in the package to match what the client want), and the official in prod (where our changes and other devs changes are merges).
I will show an example that don't work but that can help understand the idea:
[...]
"dependencies"{
[...]
"package":"prod-package"
},
"devDependencies"{
[...]
"package":"local/version/of/package"
},
and so, we should have this:
npm build # use local/version/of/package
npm build --prod # use prod-package
I'm not really good with npm (in fact, beside npm install and npm remove, I basically know nothing), so I might ask something obvious, but I can't find the answer anywere.
Have you tried using npm-link to link to the local version of the package you are consuming? That way, you could still commit your changes to the package back to the vendor.
https://docs.npmjs.com/cli/v8/commands/npm-link
You would essentially run npm link in the checked-out-from-VCS (git?) package folder, then you switch back to your project where you are consuming that package and run npm link {name-of-npm-package}
This would allow you to develop on that version locally, make your changes (and they will show up on VCS for easy pull request management).
My Environment
When I develop vue project, I keep track of files in dist folder.
My laptop
I develop vue project -> npm(yarn) run build -> git add everthing in dist folder -> git commit -> push
Production server
git pull -> Everything is good to go (since I already built dist folder on my laptop).
I have URLs of production server and localhost server in my .env file
VUE_APP_PRODUCTION_API=https://myprodserver.com/
VUE_APP_LOCAL_API=http://localhost:3000/
When I use
vue-cli-service serve, it uses localhost server url.
vue-cli-service build, it uses production server url.
(so URL is allocated in build-time, not run-time)
The Problem
But I came across a problem when I added a qa server.
Now, there are three envrionments
1. My laptop
2. qa server
3. production server
I found that vue project in qa server tries to talk to PRODUCION_API (since It pulled the dist folder for production server which I built on my laptop and committed).
What I tried
I created the .env.local in qa server and overwrote the VUE_APP_PRODUCTION_API
# qa server .env.local
VUE_APP_PRODUCTION_API=http://qaserver.com/
and installed npm, yarn
and build
it worked! But... the problem is it makes git status output dirty.
when I git status
changes:
file removed: dist/file...
file removed: dist/file...
file removed: dist/file...
file removed: dist/file...
I know I can .gitignore dist folder, and build everytime when I git pull in each environment... but that would be bothersome. that would make me have to install npm, yarn, and install whole dependency in production server too. (It wasn't necessary before since I used to build on my laptop)
Question
Do I have to build the project everytime just to change the base url?
Was it right to keep track of dist folder from the fist place?
Is there any Best-Practice you could share me?
Ideally, you would want to deploy your project using a tool like Github Actions or Gitlab CI.
This would allow you to build your projects with the necessary environment variables for the given target environment.
In general, the dist files aren't included in version control, as each developer working on your project would have different versions of it and you would encounter merging conflicts really often.
Here's an example using Github Actions, deploying on Github Pages
I have very bad internet, so I want to download the api(mongodb, react, nodejs) I need to work on a project on a local computer, tell me if this can be done?
You could probably play with "npm cache add some-package.tar.bz2" or with npm-proxy but it will probably require too much effort (or will not resolve all issues).
Alternative way would be to setup proxy server(for example squid) to keep once downloaded files localy at your server/computer.
This way you configure your system (and tools) to use yours proxy server.
So when vagrant, apt, npm, grunt or some other tool need some file from internet during the build it will download it only once and get it out of the cache of proxy server during subsequent requests.
majority of tools favour environment variables HTTP_PROXY and HTTPS_PROXY.
So you could setup docker container, virtual machine or just service (squid has windows binaries as well) and configure your system to use proxy server, i.e. add environment variables either globaly or in bash file for build process only.
Lets suppose you configured your squid at docker container with IP address 172.17.0.34. then your build script would look like:
#!/bin/bash
export HTTP_PROXY=172.17.0.34:3128
export HTTPS_PROXY=172.17.0.34:3128
npm install
For it to take global effect you could place these two lines into your /etc/environment file:
HTTP_PROXY=172.17.0.34:3128
HTTPS_PROXY=172.17.0.34:3128
cro run stops the server, recompiles, restarts the server when anything in the directory tree changes. That's great.
But when developing the client side UI, and using NPX/yarn/webpack, there is an additional step that is needed to produce the main.js file.
In the Cro tutorial this step seems to be done manually, viz., we have the line "And there we have it. npm run build, refresh, and give it a spin." Here npm run build is a command that has to be run 'manually'.
Is there a simple way, eg., using .cro.yml to force another command when changes in a sub-directory tree are detected? Eg, if the client side UI files are under path/to/cro-app/client-ui-directory and the command to be run if any files change is path/to/cro-app/client-ui/directory/yarn build
The cro-tools repo has all the file watching code associated with cro run.
So, one way would be to subclass the appropriate stuff in that repo and make a super-cro run command.
But I think the thing to do would be to set up a file watcher and trigger the rebuild in your server process. Cro files set environment variables, so you could use them to configure this behavior.
Due to clients/coworkers wish I have to switch to npm. The Project was created using Vue CLI and Yarn as default Package Manager.
I first thought no big deal, so I deleted node_modules folder and yarn.lock file. Then I ran npm install and then npm run serve.
It works and compiles like normal, recompiles when I change a file, all good so far but here is the weird part: the changes do not reflect in the browser. I have to refresh the page manually.
I tried to look into config files for vue or webpack. But there are none. No Webpack config, no vue cli config, no build folder.
What I have is:
- .eslintrc.js
- .browserlistrc
- babel.config.js
- postcss.config.js
I dont know what else to look for? Anyone any idea what this might be?
Thanks a lot,
-J
What was the cause in my case(I have Linux OS):
It seems that the value of: max_user_watches
in the /proc/sys/fs/inotify/max_user_watches
is affecting webpack => which is interfering with hot reloading.
To check your actual value
$cat /proc/sys/fs/inotify/max_user_watches
16384
16384 was in my case and it still wasn't enough.
So you will need to increase your value as well.
SOLUTION if you have Linux OS:
Create the file:
sudo nano /etc/sysctl.d/90-override.conf
And populate it with:
fs.inotify.max_user_watches=200000
It seems 200000 is enough for me, you can have a higher value if you want.
After you create the file and add the value, just restart the PC and you should be ok.
Vue CLI depends on #vue/cli-service which acts exactly like Facebook's Create React App (react-scripts).
If you are familiar with create-react-app, #vue/cli-service is roughly
the equivalent of react-scripts, although the feature set is
different.
https://cli.vuejs.org/guide/#cli-service
So what both of them do is "simplify" configuration of the project for you by hiding all the bundling configs (e.g. webpack.config.js) under the carpet. Which is handy in most cases, unless you decide to do something fancy (like switch package manager). In Create React App one can bail out from this behavior by running yarn eject or npm run eject, but on Vue CLI platform you are locked in. So there's no straightforward way to make all underlying config files to appear and fix the faulty bits in them.
To be contunued?..