Build

.eslintrc.js

@@ -4,26 +4,30 @@ module.exports = {
     browser: true,
     es2021: true,
     node: true,
-    "vue/setup-compiler-macros": true,
+    'vue/setup-compiler-macros': true,
   },
-  plugins: ["@typescript-eslint"],
-  parser: "vue-eslint-parser",
+  plugins: ['@typescript-eslint'],
+  parser: 'vue-eslint-parser',
   parserOptions: {
-    parser: "@typescript-eslint/parser",
-    sourceType: "module",
+    parser: '@typescript-eslint/parser',
+    sourceType: 'module',
     ecmaVersion: 2021,
   },
   extends: [
-    "eslint:recommended",
-    "plugin:@typescript-eslint/recommended",
-    "plugin:vue/vue3-recommended",
-    "@vue/typescript/recommended",
-    "@vue/prettier",
+    'eslint:recommended',
+    'plugin:@typescript-eslint/recommended',
+    'plugin:vue/vue3-recommended',
+    '@vue/typescript/recommended',
+    '@vue/prettier',
   ],
 
   rules: {
-    "no-console": process.env.NODE_ENV === "production" ? "warn" : "off",
-    "no-debugger": process.env.NODE_ENV === "production" ? "warn" : "off",
-    "prettier/prettier": ["warn", {}, { usePrettierrc: true }],
+    'no-console': process.env.NODE_ENV === 'production' ? 'warn' : 'off',
+    'no-debugger': process.env.NODE_ENV === 'production' ? 'warn' : 'off',
+    'prettier/prettier': ['warn', {}, { usePrettierrc: true }],
+    '@typescript-eslint/no-non-null-assertion': 0,
+    '@typescript-eslint/no-explicit-any': 0, // allow explicit any's because of the legacy code and ts-less deps, but still prohibit IMplicit any's
+    'vue/multi-word-component-names': 0,
+    'vue/no-lone-template': 0,
   },
-};
+}

.github/COMMIT_CONVENTION.md

@@ -6,19 +6,20 @@
 
 Messages must match the following regex:
 
-``` js
-/^(revert: )?(feat|fix|docs|style|refactor|test|ci|chore)(\(.+\))?: .{1,70}/
+```js
+;/^(revert: )?(feat|fix|docs|style|refactor|test|ci|chore)(\(.+\))?: .{1,70}/
 ```
 
 #### Types
-* `feat` - new functionality.
-* `fix` - patching a bug.
-* `docs` - documentation and comments.
-* `style` - style changes only (not necessarily in css).
-* `refactor` - reworking internals without impacting project interface.
-* `test` - tests and demo.
-* `ci` - deploy and continuous integration.
-* `chore` - no significant code changes: code formatting, version changes, tool updates, minor refactorings.
+
+- `feat` - new functionality.
+- `fix` - patching a bug.
+- `docs` - documentation and comments.
+- `style` - style changes only (not necessarily in css).
+- `refactor` - reworking internals without impacting project interface.
+- `test` - tests and demo.
+- `ci` - deploy and continuous integration.
+- `chore` - no significant code changes: code formatting, version changes, tool updates, minor refactorings.
 
 #### Examples
 
@@ -54,7 +55,7 @@ This reverts commit 667ecc1654a317a13331b17617d973392f415f02.
 
 ### Full Message Format
 
-A commit message consists of a **header**, **body** and **footer**.  The header has a **type**, **scope** and **subject**:
+A commit message consists of a **header**, **body** and **footer**. The header has a **type**, **scope** and **subject**:
 
 ```
 <type>(<scope>): <subject>
@@ -84,9 +85,9 @@ The scope could be anything specifying place of the commit change. For example `
 
 The subject contains succinct description of the change:
 
-* use the imperative, present tense: "change" not "changed" nor "changes"
-* don't capitalize first letter
-* no period (.) at the end
+- use the imperative, present tense: "change" not "changed" nor "changes"
+- don't capitalize first letter
+- no period (.) at the end
 
 ### Body
 

.github/CONTRIBUTING.md

@@ -2,55 +2,57 @@
 
 Hi! We are really excited that you are interested in contributing to Vuestic. Before submitting your contribution though, please make sure to take a moment and read through the following guidelines.
 
-* [Code of Conduct](./../CODE_OF_CONDUCT.md)
+- [Code of Conduct](./../CODE_OF_CONDUCT.md)
 
 ## Pull Request Guidelines
 
-* The `master` branch is just a snapshot of the latest stable release. **Do not submit PRs against the `master` branch.**
-* Atomic code contribution looks something like this:
-  * Checkout from upstream `develop`.
-  * Work on your fork in dedicated branch.
-  * When you're ready to show results - create PR against upstream `develop` and add a developer for review. You can ping said developer to speed things up ;).
-* It's OK to have multiple small commits as you work on the PR - we will let GitHub automatically squash it before merging.
+- The `master` branch is just a snapshot of the latest stable release. **Do not submit PRs against the `master` branch.**
+- Atomic code contribution looks something like this:
+  - Checkout from upstream `develop`.
+  - Work on your fork in dedicated branch.
+  - When you're ready to show results - create PR against upstream `develop` and add a developer for review. You can ping said developer to speed things up ;).
+- It's OK to have multiple small commits as you work on the PR - we will let GitHub automatically squash it before merging.
 
-* Good stuff to add in your pull request:
-  * If your PR fully resolves existing issue, add `(fix #xxxx[,#xxx])` (#xxxx is the issue id) so that github will close the issue once it's up on `master`. You have to add that to the body of PR, won't work in header :).
-  * Provide detailed description of the issue in the PR if it's not done in the issue.
-  * If you're working on visual changes - provide before/after screenshot. That speeds up review immensely.
+- Good stuff to add in your pull request:
+  - If your PR fully resolves existing issue, add `(fix #xxxx[,#xxx])` (#xxxx is the issue id) so that github will close the issue once it's up on `master`. You have to add that to the body of PR, won't work in header :).
+  - Provide detailed description of the issue in the PR if it's not done in the issue.
+  - If you're working on visual changes - provide before/after screenshot. That speeds up review immensely.
 
 ### Branches
 
-* Upstream branches (**epicmax/vuestic-admin**):
-  * `master` - stable snapshot from `develop`. Releases and hotfixes only. Do not submit PR's to `master`!.
-  * `develop` - main development branch.
+- Upstream branches (**epicmax/vuestic-admin**):
 
-* Local branches
-  * For local branches naming stick to [commit message convention](./COMMIT_CONVENTION.md). So for feature branch that adds tabs name would be `feat/tabs`.
+  - `master` - stable snapshot from `develop`. Releases and hotfixes only. Do not submit PR's to `master`!.
+  - `develop` - main development branch.
+
+- Local branches
+  - For local branches naming stick to [commit message convention](./COMMIT_CONVENTION.md). So for feature branch that adds tabs name would be `feat/tabs`.
 
 ### For core contributors
 
-* Keep amount of local branches minimal.
-* Always link PR to issue (via `fix #123`).
-* For small issues you may push to `develop` branch directly while adding (`fix #123`) to commit message.
-* Create single PR for one issue. If we have several PRs - move all the code into a single one and close the rest. If one PR covers several issues - either split it in several PRs or mark one of the issues as duplicate.
-* Be sure to have only one person assigned per issue.
-* Check your code: https://github.com/epicmaxco/vuestic-admin/issues/378.
-* We use [yarn](https://yarnpkg.com/lang/en/) for package management.
-* Be proactive. If you think something is wrong - create an issue or discuss.
-* Recommended tools: [GitKraken](https://www.gitkraken.com/), [WebStorm](https://www.jetbrains.com/webstorm/), [ShareX](https://getsharex.com/)
+- Keep amount of local branches minimal.
+- Always link PR to issue (via `fix #123`).
+- For small issues you may push to `develop` branch directly while adding (`fix #123`) to commit message.
+- Create single PR for one issue. If we have several PRs - move all the code into a single one and close the rest. If one PR covers several issues - either split it in several PRs or mark one of the issues as duplicate.
+- Be sure to have only one person assigned per issue.
+- Check your code: https://github.com/epicmaxco/vuestic-admin/issues/378.
+- We use [yarn](https://yarnpkg.com/lang/en/) for package management.
+- Be proactive. If you think something is wrong - create an issue or discuss.
+- Recommended tools: [GitKraken](https://www.gitkraken.com/), [WebStorm](https://www.jetbrains.com/webstorm/), [ShareX](https://getsharex.com/)
 
 #### Before release workflow
-* Update package versions to newest ones. Update lock files (for both `npm` and `yarn`)
+
+- Update package versions to newest ones. Update lock files (for both `npm` and `yarn`)
 
 ### Vuestic-ui
 
 Vuestic-admin uses vuestic-ui internally. So if you have some troubles with components - it's better to submit issue or PR in [respective repo](https://github.com/epicmaxco/vuestic-ui).
 
 ### Commonly used NPM scripts
 
-``` bash
+```bash
 # run dev server
-$ yarn serve
+$ yarn dev
 
 # build vuestic-admin project into bundle
 $ yarn build

.github/ISSUE_TEMPLATE.md

@@ -1,18 +1,19 @@
 **Note: for support questions, please use stackoverflow**. This repository's issues are reserved for feature requests and bug reports.
 
-* **I'm submitting a ...**
+- **I'm submitting a ...**
+
   - [ ] bug report
   - [ ] feature request
   - [ ] support request => Please do not submit support request here, see note at the top of this template.
 
-* **Do you want to request a *feature* or report a *bug*?**
+- **Do you want to request a _feature_ or report a _bug_?**
 
-* **What is the current behavior?**
+- **What is the current behavior?**
 
-* **If the current behavior is a bug, please provide the steps to reproduce, ideally also a screenshot or gif if it's a style issue**
+- **If the current behavior is a bug, please provide the steps to reproduce, ideally also a screenshot or gif if it's a style issue**
 
-* **What is the expected behavior?**
+- **What is the expected behavior?**
 
-* **What is the motivation / use case for changing the behavior?**
+- **What is the motivation / use case for changing the behavior?**
 
-* **Other information** (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)
+- **Other information** (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

.github/PULL_REQUEST_TEMPLATE.md

@@ -7,19 +7,24 @@ https://github.com/epicmaxco/vuestic-admin/blob/master/CODE_OF_CONDUCT.md
 <!-- Keep the title short and descriptive, as it will be used as a commit message -->
 
 ## Description
+
 <!-- Describe your changes in detail -->
 
 ## Markup:
+
 <!-- Paste your markup here. -->
 <details>
 
 ```vue
 // Your code
 ```
+
 </details>
 
 ## Types of changes
+
 <!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
+
 - [ ] Bug fix (non-breaking change which fixes an issue)
 - [ ] New feature (non-breaking change which adds functionality)
 - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

.husky/.gitignore

@@ -0,0 +1 @@
+_

.husky/pre-commit

@@ -0,0 +1,4 @@
+#!/bin/sh
+. "$(dirname "$0")/_/husky.sh"
+
+npx lint-staged

.prettierrc

@@ -1,10 +1,10 @@
 {
   "tabWidth": 2,
-  "semi": true,
-  "singleQuote": false,
+  "semi": false,
+  "singleQuote": true,
   "quoteProps": "as-needed",
   "trailingComma": "all",
   "bracketSpacing": true,
   "printWidth": 120,
   "vueIndentScriptAndStyle": true
-}
+}

CODE_OF_CONDUCT.md

@@ -14,21 +14,21 @@ appearance, race, religion, or sexual identity and orientation.
 Examples of behavior that contributes to creating a positive environment
 include:
 
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy towards other community members
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
 
 Examples of unacceptable behavior by participants include:
 
-* The use of sexualized language or imagery and unwelcome sexual attention or
+- The use of sexualized language or imagery and unwelcome sexual attention or
   advances
-* Trolling, insulting/derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or electronic
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic
   address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
+- Other conduct which could reasonably be considered inappropriate in a
   professional setting
 
 ## Our Responsibilities

README.ja-JP.md

@@ -62,7 +62,7 @@ npm をご使用の方：
 $ npm install
 
 # localhost:8080（デフォルト）でホットリロードを使ってサーブ
-$ npm run serve
+$ npm run dev
 
 # プロダクション用にビルド
 $ npm run build
@@ -77,7 +77,7 @@ yarn をご使用の方：
 $ yarn install
 
 # localhost:8080（デフォルト）でホットリロードを使ってサーブ
-$ yarn serve
+$ yarn dev
 
 # プロダクション用にビルド
 $ yarn build

README.md

@@ -70,7 +70,7 @@ Then, if you use npm:
 $ npm install
 
 # serve with hot reload at localhost:8080 by default.
-$ npm run serve
+$ npm run dev
 
 # build for production
 $ npm run build
@@ -85,7 +85,7 @@ If you use yarn:
 $ yarn install
 
 # serve with hot reload at localhost:8080 by default.
-$ yarn serve
+$ yarn dev
 
 # build for production
 $ yarn build

README.zh-CN.md

@@ -62,7 +62,7 @@ $ cd myproject
 $ npm install
 
 #默认情况下在localhost:8080用热重载
-$ npm run serve
+$ npm run dev
 
 #构建生产
 $ npm run build
@@ -77,7 +77,7 @@ $ npm run build --report
 $ yarn install
 
 #默认情况下在localhost:8080用热重载
-$ yarn serve
+$ yarn dev
 
 #构建生产
 $ yarn build