24 |
25 |
26 |
44 |
45 |
52 |
--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
1 | MIT License
2 |
3 | Copyright (c) 2018 The Jared Wilcurt
4 |
5 | Permission is hereby granted, free of charge, to any person obtaining a copy
6 | of this software and associated documentation files (the "Software"), to deal
7 | in the Software without restriction, including without limitation the rights
8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9 | copies of the Software, and to permit persons to whom the Software is
10 | furnished to do so, subject to the following conditions:
11 |
12 | The above copyright notice and this permission notice shall be included in all
13 | copies or substantial portions of the Software.
14 |
15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21 | SOFTWARE.
22 |
--------------------------------------------------------------------------------
/.gitignore:
--------------------------------------------------------------------------------
1 | # Logs
2 | logs
3 | *.log
4 | npm-debug.log*
5 | yarn-debug.log*
6 | yarn-error.log*
7 |
8 | # Runtime data
9 | pids
10 | *.pid
11 | *.seed
12 | *.pid.lock
13 |
14 | # Directory for instrumented libs generated by jscoverage/JSCover
15 | lib-cov
16 |
17 | # Coverage directory used by tools like istanbul
18 | coverage
19 |
20 | # nyc test coverage
21 | .nyc_output
22 |
23 | # Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files)
24 | .grunt
25 |
26 | # Bower dependency directory (https://bower.io/)
27 | bower_components
28 |
29 | # node-waf configuration
30 | .lock-wscript
31 |
32 | # Compiled binary addons (http://nodejs.org/api/addons.html)
33 | build/Release
34 |
35 | # Dependency directories
36 | node_modules/
37 | jspm_packages/
38 |
39 | # Typescript v1 declaration files
40 | typings/
41 |
42 | # Optional npm cache directory
43 | .npm
44 |
45 | # Optional eslint cache
46 | .eslintcache
47 |
48 | # Optional REPL history
49 | .node_repl_history
50 |
51 | # Output of 'npm pack'
52 | *.tgz
53 |
54 | # Yarn Integrity file
55 | .yarn-integrity
56 |
57 | # dotenv environment variables file
58 | .env
59 |
60 | dist/
61 | package-lock.json
62 |
--------------------------------------------------------------------------------
/src/sass/main.scss:
--------------------------------------------------------------------------------
1 |
2 | @charset "utf-8"; // Character type for the stylesheet
3 |
4 | // ITCSS: SETTINGS
5 | @import "_var.sass"; // Sass Variables - Does not effect page, but other Sass files reference this file.
6 |
7 |
8 | // ITCSS: TOOLS
9 | @import "_mixins.sass"; // Sass Mixins - Does not effect page, but other Sass files reference this file.
10 | @import "_functions.sass"; // Sass Functions - Does not effect page, but other Sass files reference this file.
11 |
12 |
13 | // ITCSS: RESETS - Remove inconsistencies in the way different browsers render elements by default
14 | // Not needed in a desktop app
15 |
16 |
17 | // ITCSS: FRAMEWORKS/THEMES
18 |
19 |
20 | // ITCSS: PLUGINS
21 |
22 |
23 | // ITCSS: GENERIC (ELEMENTS/BASE)
24 | @import "_base.sass"; // h1, h2, h3, p, etc.
25 | @import "_layout.sass"; // General layout classes, like .col-xs-4
26 | @import "_utility.sass"; // Utility classes, like .wrapper or .text-center
27 |
28 |
29 | // ITCSS: OBJECTS - Grouped reusable chunks
30 |
31 |
32 | // ITCSS: COMPONENTS - Component-specific styles
33 |
34 |
35 | // ITCSS: CONTAINERS
36 |
37 |
38 | // ITCSS: TRUMPS
39 | @import "_mediaqueries.sass"; // Adjusts CSS of elements depending app width. Adaptive Web Design.
40 | @import "_trumps.sass"; // Override above styles with high specificity selectors. Use sparingly
41 | @import "_shame.sass"; // Code you wrote to meet a deadline and need to fix later
42 |
--------------------------------------------------------------------------------
/src/components/restrictions.vue:
--------------------------------------------------------------------------------
1 |
2 |
3 |
Restrictions in ".vue" files:
4 |
This boilerplate does not use a bundler, which means there are some restrictions around how you should write your code.
5 |
6 |
Usage of .vue files is allowed with the help of "http-vue-loader". However, this means your .vue files run directly in the browser.
7 |
No usage of meta-languages (Sass/HAML/Pug/scss/etc) is allowed in .vue files, because .vue files are ran in the browser and the browser doesn't understand meta-languages.
8 |
9 | You can import any Node module and use it in your code, however when requiring them inside .vue files, you have to use nw.require.
10 |
11 |
const path = nw.require('path');
12 |
13 |
14 |
15 | When referencing a globally declared variable, like something on the window object, in the template section of a component, you will need to create a computed value that returns the global item of the same name.
16 |
You may only use the parts of ES6+ that are already supported in Chromium {{ chromiumVersion }} or Node {{ nodeVersion }}.
33 |
You may use parts of ES6+ not supported in this version of Chromium/Node, but you will need to supply polyfills, or transpile to ES5.
34 |
35 |
36 |
37 |
38 |
51 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 |
2 | # vue-desktop-basic boilerplate
3 |
4 |
5 | ## What is this
6 |
7 | This is a boilerplate for a simple desktop app. It comes with tips about common tasks for a desktop app.
8 |
9 |
10 | ## Should I use this
11 |
12 | Probably not? It's more of a proof of concept to see if you can run all of the features of a Vue app without the need for a bundler, since the process of bundling is pretty pointless for a desktop app (no point in shaving off 25KB when you are shipping 100MB).
13 |
14 | Still though, there are a lot of good tips for NW.js apps in there in general, that are applicable to any desktop app, whether it is using Vue & NW.js or React & Electron.
15 |
16 | **What should I use instead?**
17 |
18 | * [NW.js + Vue 3 + Vite + Pinia + Vitest + Vue-DevTools](https://github.com/nwutils/nw-vue3-boilerplate) - This the newest/most robust/best option for desktop apps with Vue.
19 | * [NW-Vue-CLI-Example](https://github.com/nwutils/nw-vue-cli-example) is basically a normal Vue-CLI project with some additional setup already added in to work as a desktop app.
20 |
21 |
22 | ### Features
23 |
24 | The following are already set up:
25 |
26 | * Vue.js
27 | * Vue-Router
28 | * Vuex
29 | * Vue-DevTools
30 | * Sass
31 | * Sasslint
32 | * ESLint
33 | * nwjs-builder-phoenix
34 | * [VSCode intellisense for nw](http://docs.nwjs.io/en/latest/For%20Users/FAQ/)
35 |
36 |
37 | ## Usage
38 |
39 | 1. Download and install [Node.js](https://nodejs.org)
40 | 1. Download `vue-desktop-basic`
41 | 1. Run `npm install`
42 | 1. Run `npm start`
43 |
44 |
45 | ## Linting
46 |
47 | 1. `npm run lint` will lint your `.js` and `.vue` files according to the rules in `.eslintrc.js`
48 | 1. `npm run fix` this will auto-fix any linting issues that `npm run lint` finds (not everything can be auto fixed)
49 | 1. `npm run sass` will start watching for changes in the sass folder and process the changes to the css folder.
50 | 1. `npm run sasslint` will lint your `.sass` and `.scss` files.
51 | 1. `npm run sassfix` will attempt to auto-fix Sass linting issues, however it may take several runs and not everything can be auto fixed
52 |
53 |
54 | ## To do a build:
55 |
56 | 1. `npm install`
57 | 1. `npm run build`
58 |
59 | All settings regarding the build are handled in the `package.json`.
60 |
61 |
62 | ### Vue-DevTools
63 |
64 | If you want Vue-DevTools to be accessible in the Chromium DevTools in your app, you cannot use the minified version of Vue.js (use `vue.js` not `vue.min.js`).
65 |
66 |
67 | * * *
68 |
69 | All other instructions and details are inside the app.
70 |
71 | * * *
72 |
73 | ### TO DO List:
74 |
75 | * Add in Vue-Test-Utils
76 |
--------------------------------------------------------------------------------
/src/components/reasoning.vue:
--------------------------------------------------------------------------------
1 |
2 |
3 |
Reasoning:
4 |
Why not use a bundler, like WebPack/Browserify/Parcel/StealJS/Fuse-Box/Etc?
5 |
6 |
Because bundlers are designed around the limitations of the web. We are working with a different medium, Cross-Platform Desktop Apps (XPDAs).
7 |
The purpose of a bundler is to bundle our code. Features like concatenating, tree-shaking, uglifying, and minifying our code doesn't really offer any benefit. Nor does reducing the number of simultaneous network requests for assets. All assets are local, because desktop apps should follow the best practice of "offline-first".
8 |
Ultimately you are shipping an 80+ MB app to your end user, so the tiny optimizations made for the medium of web are quite arbitrary here.
9 |
A much greater concern for desktop apps would be the amount of dependencies in your node_modules folder, since all dependencies, and their dependencies are shipped to the end user (this excludes devDependencies). For more detailed information on optimizing for desktop apps read this article:
10 |
If you wish to use additional features for development (linting, HMR, Sass, etc), I would recommend adding those features via a task runner, like Gulp, or just via simple npm scripts.
15 |
16 |
Why not use a CDN for Vue/Vue-Router/Vuex/Etc instead of adding them as dependencies?
17 |
18 |
Because for desktop apps you should always be designing with an "offline-first" mentality. Your app should still run if the user is in Airplane mode.
19 |
Keeping them as dependencies allows you to easily handle version management.
20 |
An alternative option would be to create a script that downloads the desired versions of these libraries into an untracked folder. This would mean you would have the desired versions, and no additional files or dependencies. Then run that script as a postinstall npm script. The downside to this is that it would be less familiar to other developers. Though technically more efficient, it is also slightly less maintable and requires documentation for future maintainers/contributors.
6 | A best practice is to store your user's settings as a json file in nw.App.dataPath. This location is specific to the currently logged in computer user, your app, and the OS. On your computer the path would be:
7 |
13 | When linking to an external website, you must explicitly tell NW.js to open the user's default browser. Otherwise you will navigate away from your app to the new URL.
14 |
52 | When handling CSS, because all code will only be ran in 1 browser (Chromium):
53 |
54 |
You do not need to use CSS Resets or Normalizers. Whatever CSS works for you will work for 100% of your end users because you are handing them the browser you developed on.
55 |
You can remove all vendor prefixes, unless it is for a feature not yet implemented in this version of Chromium.