I'm curious to know how can one manage application settings in an Electron application? I have found some excellent resources here (Where to store user settings in Electron (Atom Shell) Application?, for example) and elsewhere when it comes to managing user settings but couldn't find anything related to managing application settings.
To me, the difference between the two is that application settings could vary from environment to environment (dev/test/production) but would remain the same for all users of the application. They would contain things like API endpoints etc. User settings on the other hand would change from user to user based on their preferences like window width/height etc.
What I have done so far?
I have found this excellent package called config and start using it in my project. Based on the instructions, I have created a config folder and a default configuration file (I will create environment specific configuration files later).
It is working fine as long as I am developing the application. The application is picking up the default.json file properly from the config folder and is applying those settings correctly.
The problem comes when I package the application (MSI, DMG etc.). I am using electron-builder package for that purpose.
The problem with config package is that it looks for config folder inside the application's current working directory and because it doesn't find it in the folder where the application is installed, it simply throws an error. I even tried to manually copy this folder in my app folder (which is where electron-builder makes the packages) but that didn't help either. Ideally I would like to bundle the app settings in application's ASAR file so that it can't be decompiled.
My questions are:
How are people managing application settings for an Electron application?
Can config NPM package be used for that? Or is there an alternative to that package specifically for Electron applications?
I am not using an npm package but my approach is similar to what you have mentioned. I have a config directory with different config files for different environments: dev, test, prod. Then in my package.json I have added environment specific build commands. e.g. For prod:
"build-prod-config": "config/buildProdConfig.sh",
"build-renderer-prod": "webpack --config=webpack.config.renderer.prod.js",
"build-main-prod": "webpack --config=webpack.config.main.prod.js",
"build-prod": "npm run build-prod-config && npm run build-main-prod & npm run build-renderer-prod",
buildProdConfig.sh
#!/usr/bin/env bash
cp config/app.config.prod.js config/app.config.js
echo "Copied ProdConfig to Config"
//This is what a config file looks like
const Config = {
suppDataDirectoryPath: '/suppData/',
builtFor: 'prod',
}
module.exports = Config;
I then require Config whereever I need in my application and use the values. This is a simple thing for now, and perhaps doesn't have the flexibility of the config package you linked to, but it works.
Also, another important thing is that I am not packing my application into an ASAR archive, but I think my approach would still work because I am packing everything into a bundle using webpack.
Related
From the Vue CLI https://cli.vuejs.org/guide/deployment.html, it stated that the dist directory is meant to be served by an HTTP server. But why can't I preview it from the index.html? Cause my understanding is that Vue is just a front end JavaScript framework, so one should be able to preview it from any browser. If am to create a simple vue project using a cdn, it can be directly previewed on the browser. But this is not the case for the vue project created through the CLI. Can someone explain this.
Take a look into the Chrome Dev Tools. You will see a couple of errors similar to those:
As you can see, there are a bunch of files that fail to be imported. This is because these files are not imported using a relative file path, but an absolute one (starting from root, as visible by the prepended / in all files in the index.html).
If you run a local server from the dist directory root will resolve to this directory, allowing the files to be imported properly and your site to be visible in the browser.
However if you simply open the index.html file in your browser, / will resolve to the root of your operating system, which does not contain the files. If you were to copy all those files into the root of your OS, so that the paths would resolve successfully, you would not need a server to view your Vue application.
CLI projects are built with the use on a server in mind. The idea is to just be able to deploy the files in the dist directory to a server and have a working Vue application.
Just to add to a great answer from #aside.
You can use a publicPath configuration option of Vue CLI and set it to '' or ./ - this should be enough to make it work from file system
The value can also be set to an empty string ('') or a relative path (./) so that all assets are linked using relative paths. This allows the built bundle to be deployed under any public path, or used in a file system based environment like a Cordova hybrid app.
vue.config.js
module.exports = {
publicPath: ''
}
It's my first time I'm trying to do that.
I'd like to set up config file in circle.ci in order to deploy my React app to expternal server. Before I just used Ftp connection to upload files to the production server. But now I'd like to do that authomatically. So in my circle config file I've already configured steps to run yarn install and yarn build, all is just doing fine, but the last step needs to be done, I basically have no knowledge how to connect it all, ie. files comes from github, then they are used for build purpose by circle.ci, then I'd like to deploy it to the production server. What is the flow here, and what should I use (ssh somehow, but how?). Thanks
If you're hosting provider supports it, I would suggest using rsync over FTP since it will ensure files are replicated without needing to upload everything, only changes. The --delete option will al\so remove extraneous files on the webhost that you may have removed from github.
- run:
name: Deploy public folder to YOURDOMAIN
command: |
rsync -avz --delete /local/path/ USERNAME#HOSTNAME:/Path/on/remote/server/
if yo have not made any changes to default CIrcleCI images, your local path is likely /home/circleci/project/
Problem description:
I have an electron application and I need to add the application to user environment variables after users install my application, so that they can run commands like this my-electron-app <command> [<args>] in the terminal to start my electron application.
I could not find a way to do this programmatically using nodejs. VSCode, hyper and atom are the three electron apps ( that I know of ) who add the application path to user environment variables after users install the application.
I'm using electron builder to build an NSIS installer. I couldn't find any options there either that serve the purpose.
Question:
How can I add my electron application to user environment variables after users install my application on their system, so that they can launch my electron app from terminal by running commands like this my-electron-app start?
I am blindly guessing here since I have simply browsed through the code for a couple of minutes: There seems to be a post install step which is maybe also used in Hyper here somehow. This script places a file in a folder that is probably in the user's PATH. More about the PATH environment variable here.
This seems like a situation that must be incredibly common, but I've yet to find a good solution to it. I'm a little new to modern Javascript, so please forgive me (or better yet, correct me) if I'm using the wrong terminology here and there.
I'm developing a web application. It's got a server, running as Javascript (ES6, I believe - using import/export) in node.js, using express.js for a router (and built by express-cli). And it's got a client side, also Javascript, mostly Vue modules (and built by vue-cli). I admit I don't really understand a lot of the boilerplate build code express-cli and vue-cli emitted, but it does work. I am not using any of a long list of frameworks that are assumed in the many pages google found for me when I tried to find an answer to this question.
Obviously, the client and server will be sending data structures (instances of various classes) back and forth, which I know how to do. And these ought to be the same class definitions.
I made an attempt to make webpack build both server and client, and that failed, so now I've split the application into two projects, each with its own folder tree, its own package.json, its own node_modules, and I'm using just webpack-dev-server for the client and nodemon/babel for the server. A third folder contains the shared code, which is imported by the client and the server. I got this to work well enough for proof of concept, but getting both sides (and Visual Studio Code) to recognize that the shared code is part of them is turning out to be a challenge, and I'm pretty sure I'm just going down the wrong path.
So, my question is, what is currently considered the best practice (or at least, a good practice) way to structure and build a client/server application of this type? An ideal answer to this question would include both folder structure and enough of the major configuration files to help me figure out how to write mine. A reference to an up-to-date and reliable source of information on this topic would satisfy me nicely.
I suspect that the right answer includes merging everything back into a single project and doing something clever with the webpack config files and maybe project.json... but what exactly that clever thing might be has so far eluded me.
Thanks!
In my opinion, you're right to use separate folders for your node.js(server)/vue.js(client app) as they're effectively 2 separate projects.
Apart from sharing some configs, utilities and validation, the app and server typically have little overlap: they're typically doing 2 very different things, require different build tools, different runtime environments, have different security concerns, and if you consider the future possibility of leveraging your client codebase to create a native IOS/android... app the difference between the 2 codebases will only increase.
For my current project, I have a folder structure whereby my server resides in the project root and my client is in a subfolder /app. Here's an simplified outline of how I've structured my node.js/vue.js project:
constants
config.js (server environment, database connection, api keys etc)
settings.js (business logic)
pricing.js
drivers
auth.js
db-connect.js
email.js
sms.js
socket-io-server.js
models (mongoose database models)
node_modules
routes (express routes)
api.js
auth.js
schema (json schema for automated validation)
login-validation.js
register-validation.js
services
billing.js
validation.js
app (this is my client sub-project sharing some server modules)
public (the output of the webpack client bundle including index.html)
src (ES6 source code, images, SASS/Stylus, fonts etc)
css
html (handlebars templates)
index.hbs
home.hbs
account.hbs
pricing.hbs
img
js
api
client-services
socket-io-client.js
store.js
router.js
vuex-utils.js
dom-utils.js
components (Vue components)
Profile.vue
Payment.vue
index.js (root and entry point for webpack)
webpack.config.js
.env.development.js
.env.production.js
package.json
server.js (node.js server root entry point)
This is by no means prescriptive. Notice, that I've organized the project files largely by function. Here's a link to an article proposing structuring around features.
A shared (client/server) module folder has pros and cons. The main downside I can see is that module sharing changes during development. For that reason my server codebase and modules reside in the project root folder - and some are also imported by the client app. The project root folder then naturally hosts a shared package.json and node_modules folder.
As your app develops, and you gain insight, it's fine to re-structure as the need arises (some IDEs make refactoring easier than others). If the Visual Studio Code IDE or webpack are not working well with your folder structure, it may be a configuration issue or the problem may stem from incorrect require/import paths. IDE inspections may help you find those errors or your IDE may struggle to be useful because of those errors.
My IDE (webstorm) and webpack v4 have no problems with the above folder structure or the location of modules in general (I have re-structured my app in many different ways) and got more adept at optimally configuring my IDE and webpack.
Webpack is very specific about the location of it's configuration file, input/output paths, whether it is executed from the project root or /app folder and it can take a lot of time to get it working properly. Nevertheless, it will locate modules referenced by the correct require/import paths. Here's the part of my webpack.config.js that sets up file entry/output.
const sourcePath = './src';
module.exports = {
entry: [
sourcePath + '/js/index.js'
],
output: {
path: __dirname + '/public', //location of webpack output files
publicPath: '/', //address that browser will request the webpack files
filename: 'js/index.[contenthash].js', //output filename
chunkFilename: 'js/chunk.[contenthash].js' //chunk filename
},
...
I've located my webpack.config.js and execute webpack inside the /app subfolder. My package.json scripts section to start the node.js server and have webpack build & watch my app files is:
"scripts": {
"start": "if [$NODE_ENV == 'production']; then node server.js; else nodemon server.js; fi",
"build": "cd ./app; webpack;"
},
Which allows me to start the node server with:
> npm start
and have webpack watch/re-build my bundle with:
> npm run build
Visual Studio Code has a rich IntelliSense experience and a feature called Automatic Type Acquisition which should allow it to support modules you import regardless of their location. This article provides more information on configuring VS Code for node.js.
I have been building my application on web pack and testing using web pack. My biggest concerned is how can deploy it after the application is complete?
Do i need to use the 'Webpack' dev server for production or just deploy direct my 'dist' folder to production.
No, you should not use webpack dev server on prod, and it's particularly said in docs. Yes, you should make a build with webpack, probably using another config (or having conditions in your config, e.g. depending on ENV variables). For example, you would probably want to run minifiers, or hash your files for cache busting. And then you just upload dist to your webserver (if you don't use any CI tools of course, in that case you should run a build there) and run apache, nginx or anything else there.