@winjs-dev/create-win 1.0.0-alpha.2

package/templates/pc/.cursor/rules/clean-code.mdc

@@ -0,0 +1,55 @@
+---
+description: Guidelines for writing clean, maintainable, and human-readable code. Apply these rules when writing or reviewing code to ensure consistency and quality.
+globs: 
+---
+# Clean Code Guidelines
+
+## Constants Over Magic Numbers
+- Replace hard-coded values with named constants
+- Use descriptive constant names that explain the value's purpose
+- Keep constants at the top of the file or in a dedicated constants file
+
+## Meaningful Names
+- Variables, functions, and classes should reveal their purpose
+- Names should explain why something exists and how it's used
+- Avoid abbreviations unless they're universally understood
+
+## Smart Comments
+- Don't comment on what the code does - make the code self-documenting
+- Use comments to explain why something is done a certain way
+- Document APIs, complex algorithms, and non-obvious side effects
+
+## Single Responsibility
+- Each function should do exactly one thing
+- Functions should be small and focused
+- If a function needs a comment to explain what it does, it should be split
+
+## DRY (Don't Repeat Yourself)
+- Extract repeated code into reusable functions
+- Share common logic through proper abstraction
+- Maintain single sources of truth
+
+## Clean Structure
+- Keep related code together
+- Organize code in a logical hierarchy
+- Use consistent file and folder naming conventions
+
+## Encapsulation
+- Hide implementation details
+- Expose clear interfaces
+- Move nested conditionals into well-named functions
+
+## Code Quality Maintenance
+- Refactor continuously
+- Fix technical debt early
+- Leave code cleaner than you found it
+
+## Testing
+- Write tests before fixing bugs
+- Keep tests readable and maintainable
+- Test edge cases and error conditions
+
+## Version Control
+- Write clear commit messages
+- Make small, focused commits
+- Use meaningful branch names 

package/templates/pc/.cursor/rules/general.mdc

@@ -0,0 +1,51 @@
+---
+description: WinJS 前端编码通用规则
+globs: ["**/*.js", "**/*.ts", "**/*.vue" ]  # 适用的文件模式
+alwaysApply: false  # 是否始终应用
+---
+
+## 角色
+你是一名资深前端开发工程师，并且是 Vue2/3、NuxtJS、JavaScript、TypeScript、HTML、CSS以及现代用户界面/用户体验框架（例如TailwindCSS、ShadcnUI、Radix、Element-UI、VantUI、AntDesignUI、VuetifyUI、BootstrapUI、MaterialUI、MantineUI、ChakraUI、HeadlessUI、SkeletonUI、QuasarUI、IonicUI、FluentUI、SemanticUI、IcoMoonUI、IcoFontUI、FontAwesomeUI、EvaIconsUI、MaterialIconsUI、TablerIconsUI、BoxIconsUI）方面的专家。你思维缜密，能够给出细致入微的答案，并且在推理方面才华出众。你会认真地提供准确、真实、周全的答案，是推理方面的天才。
+
+你应始终遵循一下规则：
+
+## 编写代码时：
+- 仔细且严格地遵循用户的要求。
+- 首先要逐步思考——用伪代码详细描述你要构建内容的计划。
+- 确认计划后，再编写代码！- 始终编写正确的、符合最佳实践的、遵循DRY原则（不要重复自己）的、无错误的、功能完备且能正常运行的代码，同时代码应符合下面"代码实现指南"中列出的规则。
+- 相比于追求性能，更要专注于编写简洁易读的代码。
+- 完整实现所有要求的功能。
+- 不要留下待办事项、占位符或缺失的部分。
+- 确保代码是完整的！要彻底检查并最终确定。
+- 包含所有必需的导入，并确保关键组件的命名恰当。
+- 简洁明了，尽量减少其他不必要的文字表述。
+- 如果你认为可能不存在正确答案，要如实说明。
+- 如果你不知道答案，直接说明，而不要猜测。
+- 代码结构：强调代码的清晰性、模块化、可维护性，遵循最佳实践（如 DRY 原则、最小权限原则、响应式设计等）。
+- 代码安全性：在编写代码时，始终考虑安全性，避免引入漏洞，确保用户输入的安全处理。
+- 性能优化：优化代码的性能，减少资源占用，提升加载速度，确保项目的高效运行。
+- 测试与文档：编写单元测试，确保代码的健壮性，并提供清晰的中文注释和文档，方便后续阅读和维护。
+
+## 技术栈：
+- ReactJS
+- VueJS
+- NextJS
+- NuxtJS
+- JavaScript
+- TypeScript
+- TailwindCSS
+- HTML
+- CSS
+
+## 代码实现指南编写代码时请遵循以下规则：
+- 尽可能使用提前返回（early returns），以使代码更具可读性。
+- 始终使用Tailwind类来设置HTML元素的样式；避免使用CSS或标签样式。
+- 只要有可能，在类标签中使用"class:"而不是三元运算符。
+- 使用描述性的变量和函数/常量名称。此外，事件函数应以"handle"作为前缀命名，例如，onClick事件对应的函数命名为"handleClick"，onKeyDown事件对应的函数命名为"handleKeyDown"。
+- 在元素上实现可访问性特性。例如，一个标签应该有tabindex="0"、aria-label、on:click和on:keydown等类似属性。
+- 使用常量（const）而不是函数，例如，"const toggle = () =>"。并且，尽可能定义类型。
+
+## 规范
+1. 编码规范
+- `.js/.ts/.vue/.jsx/.tsx`：使用`@winner-fed/f2elint`进行代码检查。
+- `.js/.ts/.vue/.jsx/.tsx`：使用`prettier`进行代码格式化。

package/templates/pc/.cursor/rules/git-conventional-commit-messages.mdc

@@ -0,0 +1,127 @@
+---
+description:
+globs:
+alwaysApply: false
+---
+
+# Git 提交流程
+
+# 步骤一
+进行 Code Review，若遇到 git 命令分页的情况，请加上`| cat`，分析是存在以下几种级别的问题：
+
+## 严重
+- 分析是否包含敏感信息，如密码、密钥、证书等
+
+## 警告
+- 分析是否有破坏性的代码改动，如有则需要全部列举出来
+- 分析是否有明显的性能问题，进行说明并给出优化建议
+
+## 提醒
+- 分析本次代码改动的影响范围，以简洁的语言进行描述
+- 分析代码是否已经格式化
+
+
+# 步骤二
+
+## 提交信息格式：
+
+提交信息应遵循以下格式：
+
+```
+<type>(<scope>): <subject>
+
+[optional body]
+
+[optional footer(s)]
+```
+
+提交信息涉及换行时使用多个 -m 参数提交，如：
+
+```
+git commit -m "feat(auth): 添加用户登录功能" -m "实现了基于 JWT 的用户登录认证功能：" -m "- 添加登录接口" -m "- 实现 token 生成和验证" -m "- 添加用户信息缓存" -m "Closes #123"
+```
+
+### type 类型包括：
+- feat: 新功能 ✨
+- fix: 修复 bug 🐛
+- docs: 文档更新 📚
+- style: 代码格式调整，不影响代码逻辑 🎨
+- refactor: 重构代码，不修复 bug 也不添加新功能 🧹
+- test: 添加或修改测试代码 🧪
+- chore: 构建过程或辅助工具的变动 🔧
+
+### scope 范围包括：
+- 模块名（如：auth、user、order、product等）
+- 文件名（如：index、login、register等）
+- 函数名（如：login、register、getUserInfo等）
+- 组件名（如：Button、Input、Table等）
+- 路由名（如：/login、/register、/user/:id等）
+- 接口名（如：getUserInfo、createOrder等）
+- 变量名（如：user、order、product等）
+- 常量名（如：API_BASE_URL、API_TIMEOUT等）
+- 枚举名（如：UserRole、OrderStatus等）
+- 类型名（如：User、Order、Product等）
+- 接口名（如：UserService、OrderService、ProductService等）
+- 其他（如：config、env、utils等）
+
+### Subject 主题
+
+- 用简短的语言描述本次提交的主要内容
+- 不超过 50 个字符
+- 以动词开头，使用第一人称现在时
+- 第一个字母小写
+- 结尾不加句号
+
+### Body 正文
+
+- 对本次提交的详细描述
+- 可以分成多行
+- 说明代码变动的动机，以及与以前行为的对比
+
+### Footer 页脚
+
+- 用于关联 Issue 或破坏性变更说明
+- Breaking Changes 必须以 `BREAKING CHANGE:` 开头
+- 关联 Issue 使用 `Closes #123, #456`
+
+## 示例
+
+```
+feat(auth): 添加用户登录功能
+
+实现了基于 JWT 的用户登录认证功能：
+- 添加登录接口
+- 实现 token 生成和验证
+- 添加用户信息缓存
+
+Closes #123
+```
+
+```
+fix(api): 修复用户查询接口返回错误
+
+修复了当用户不存在时返回 500 错误的问题，
+现在会正确返回 404 状态码。
+
+Closes #456
+```
+
+## 规范详情
+
+本文档中的关键词 “必须（MUST）”、“不得（MUST NOT）”、“要求（REQUIRED）”、“应（SHALL）”、“不应（SHALL NOT）”、“应该（SHOULD）”、“不应该（SHOULD NOT）”、“推荐（RECOMMENDED）”、“可以（MAY）” 和 “可选（OPTIONAL）” 应按照 RFC 2119 中的描述进行解释。
+提交记录必须以一个类型作为前缀，该类型由一个名词（如 “feat”（新特性）、“fix”（修复）等）组成，后面可选择性地跟作用域、可选择性地跟 “!”，以及必须有的冒号和空格。
+当提交为你的应用程序或库添加了新功能时，必须使用类型 “feat”。
+当提交表示对你的应用程序的一个错误修复时，必须使用类型 “fix”。
+在类型之后可以提供一个作用域。作用域必须由一个名词组成，该名词描述代码库的一个部分，并用括号括起来，例如 “fix (parser):” 。
+在类型 / 作用域前缀后的冒号和空格之后，必须紧接着是一段描述。这段描述是对代码变更的简短总结，例如 “fix: 修复字符串中包含多个空格时的数组解析问题”。
+在简短描述之后可以提供更长的提交内容主体，以提供关于代码变更的更多背景信息。主体必须在描述之后空一行开始。
+提交内容主体格式自由，可以由任意数量的以换行符分隔的段落组成。
+在内容主体之后空一行，可以提供一个或多个脚注。每个脚注必须由一个单词标记组成，后面跟着 “:< 空格 >” 或 “< 空格 >#” 分隔符，再后面跟着一个字符串值（这受到了 git trailer 约定的启发）。
+脚注的标记必须使用 “-” 来代替空白字符，例如 “Acked-by”（这有助于将脚注部分与多段落的内容主体区分开来）。“BREAKING CHANGE” 是个例外，它也可以用作标记。
+脚注的值可以包含空格和换行符，并且当观察到下一个有效的脚注标记 / 分隔符对时，解析必须终止。
+重大变更必须在提交的类型 / 作用域前缀中指明，或者作为脚注中的一项来指明。
+如果作为脚注包含在内，重大变更必须由大写文本 “BREAKING CHANGE” 组成，后面跟着一个冒号、一个空格和一段描述，例如 “BREAKING CHANGE: 现在环境变量优先于配置文件”。
+如果包含在类型 / 作用域前缀中，重大变更必须通过在冒号之前紧邻一个 “!” 来指明。如果使用了 “!”，则脚注部分中可以省略 “BREAKING CHANGE:”，并且提交描述应该用于描述该重大变更。
+除了 “feat” 和 “fix” 之外的其他类型也可以用在你的提交信息中，例如 “docs: 更新参考文档”。
+构成规范提交的信息单元，实现者不得将其视为区分大小写，“BREAKING CHANGE” 除外，它必须是大写的。
+当 “BREAKING-CHANGE” 在脚注中用作标记时，它必须与 “BREAKING CHANGE” 同义。

package/templates/pc/.cursor/rules/gitflow.mdc

@@ -0,0 +1,111 @@
+---
+description: Gitflow Workflow Rules. These rules should be applied when performing git operations.
+---
+# Gitflow Workflow Rules
+
+## Main Branches
+
+### main (or master)
+- Contains production-ready code
+- Never commit directly to main
+- Only accepts merges from:
+  - hotfix/* branches
+  - release/* branches
+- Must be tagged with version number after each merge
+
+### develop
+- Main development branch
+- Contains latest delivered development changes
+- Source branch for feature branches
+- Never commit directly to develop
+
+## Supporting Branches
+
+### feature/*
+- Branch from: develop
+- Merge back into: develop
+- Naming convention: feature/[issue-id]-descriptive-name
+- Example: feature/123-user-authentication
+- Must be up-to-date with develop before creating PR
+- Delete after merge
+
+### release/*
+- Branch from: develop
+- Merge back into: 
+  - main
+  - develop
+- Naming convention: release/vX.Y.Z
+- Example: release/v1.2.0
+- Only bug fixes, documentation, and release-oriented tasks
+- No new features
+- Delete after merge
+
+### hotfix/*
+- Branch from: main
+- Merge back into:
+  - main
+  - develop
+- Naming convention: hotfix/vX.Y.Z
+- Example: hotfix/v1.2.1
+- Only for urgent production fixes
+- Delete after merge
+
+## Commit Messages
+
+- Format: `type(scope): description`
+- Types:
+  - feat: New feature
+  - fix: Bug fix
+  - docs: Documentation changes
+  - style: Formatting, missing semicolons, etc.
+  - refactor: Code refactoring
+  - test: Adding tests
+  - chore: Maintenance tasks
+
+## Version Control
+
+### Semantic Versioning
+- MAJOR version for incompatible API changes
+- MINOR version for backwards-compatible functionality
+- PATCH version for backwards-compatible bug fixes
+
+## Pull Request Rules
+
+1. All changes must go through Pull Requests
+2. Required approvals: minimum 1
+3. CI checks must pass
+4. No direct commits to protected branches (main, develop)
+5. Branch must be up to date before merging
+6. Delete branch after merge
+
+## Branch Protection Rules
+
+### main & develop
+- Require pull request reviews
+- Require status checks to pass
+- Require branches to be up to date
+- Include administrators in restrictions
+- No force pushes
+- No deletions
+
+## Release Process
+
+1. Create release branch from develop
+2. Bump version numbers
+3. Fix any release-specific issues
+4. Create PR to main
+5. After merge to main:
+   - Tag release
+   - Merge back to develop
+   - Delete release branch
+
+## Hotfix Process
+
+1. Create hotfix branch from main
+2. Fix the issue
+3. Bump patch version
+4. Create PR to main
+5. After merge to main:
+   - Tag release
+   - Merge back to develop
+   - Delete hotfix branch 

package/templates/pc/.cursor/rules/project-structure.mdc

@@ -0,0 +1,69 @@
+---
+description: Defines the recommended folder structure for a WinJS project to maintain consistency and organization.
+globs: src/**/*
+---
+
+- Recommended folder structure:
+  - `config`：
+    - `config.ts`：配置文件
+  - `dist`：存放构建输出结果的目录
+  - `mock`：
+    - `app.ts｜tsx`：模拟相关的代码文件
+  - `public`：存放静态资源的目录
+  - `src`：
+    - `.win`：临时文件目录
+    - `.win-production`：生产环境临时文件目录
+    - `assets`：
+      - `fonts`：字体文件目录
+      - `img`：图片文件目录
+      - `style`：样式文件目录
+      - `js`：js文件目录
+    - `components`：
+      - `componentName`：组件名称，采用大驼峰规范
+        - `index.ts`：组件入口文件
+        - `index.less`：组件样式文件
+        - `index.vue`：组件文件
+    - `icons`: svg 图标文件目录
+    - `layouts`：
+      - `BasicLayout.vue`：基础布局组件
+      - `index.less`：布局相关样式文件
+    - `models`：
+      - `global.ts`：全局数据模型相关文件
+      - `index.ts`：数据模型入口文件
+    - `pages`：
+      - `index.less`：页面样式文件
+      - `index.vue`：页面组件
+    - `utils`（推荐目录）：
+      - `index.ts`：工具函数文件
+    - `services`（推荐目录）：
+      - `api.ts`：网络请求相关文件
+    - `app.(ts|tsx)`：运行时配置文件
+    - `constant.(ts|js)`：定义常量的文件
+    - `global.ts`：全局相关文件
+    - `global.(css|less|sass|scss)`：全局样式文件
+    - `overrides.(css|less|sass|scss)`：样式覆盖文件
+    - `favicon.(ico|gif|png|jpg|jpeg|svg|avif|webp)`：站点图标文件
+  - `node_modules`：
+    - `.cache`：
+      - `bundler-webpack`：webpack 打包缓存相关
+      - `mfsu`：模块联邦服务工具相关缓存
+      - `mfsu-deps`：模块联邦服务工具依赖相关缓存
+  - `.env`：环境变量配置文件
+  - `.editorconfig`：编辑器编码风格配置文件
+  - `.eslintignore`：eslint 校验忽略文件
+  - `.eslintrc.js`：eslint 校验配置文件
+  - `.gitignore`：git 忽略文件
+  - `.npmrc`：npm 源地址配置文件
+  - `.markdownlint.json`：markdown lint 工具配置文件
+  - `.markdownlintignore`：markdown lint 忽略文件
+  - `.prettierignore`：prettier 代码格式化忽略文件
+  - `.prettierrc.js`：prettier 代码格式化配置文件
+  - `.stylelintrc.js`：stylelint css 代码规范配置文件
+  - `.stylelintignore`：stylelint css 忽略文件
+  - `commitlint.config.js`：git commit 规范配置文件
+  - `f2elint.config.js`：f2elint 配置文件
+  - `plugin.ts`：用于定制项目需求的文件
+  - `.winrc.ts`：与`config/config`文件二选一的配置文件
+  - `package.json`：项目依赖管理及脚本配置文件
+  - `tsconfig.json`：TypeScript 编译配置文件
+  - `typings.d.ts`：类型声明文件

package/templates/pc/.cursor/rules/typescript.mdc

@@ -0,0 +1,57 @@
+---
+description: TypeScript coding standards and best practices for modern web development
+globs: **/*.ts, **/*.tsx, **/*.d.ts
+---
+
+# TypeScript Best Practices
+
+## Type System
+- Prefer interfaces over types for object definitions
+- Use type for unions, intersections, and mapped types
+- Avoid using `any`, prefer `unknown` for unknown types
+- Use strict TypeScript configuration
+- Leverage TypeScript's built-in utility types
+- Use generics for reusable type patterns
+
+## Naming Conventions
+- Use PascalCase for type names and interfaces
+- Use camelCase for variables and functions
+- Use UPPER_CASE for constants
+- Use descriptive names with auxiliary verbs (e.g., isLoading, hasError)
+- Prefix interfaces for React props with 'Props' (e.g., ButtonProps)
+
+## Code Organization
+- Keep type definitions close to where they're used
+- Export types and interfaces from dedicated type files when shared
+- Use barrel exports (index.ts) for organizing exports
+- Place shared types in a `types` directory
+- Co-locate component props with their components
+
+## Functions
+- Use explicit return types for public functions
+- Use arrow functions for callbacks and methods
+- Implement proper error handling with custom error types
+- Use function overloads for complex type scenarios
+- Prefer async/await over Promises
+
+## Best Practices
+- Enable strict mode in tsconfig.json
+- Use readonly for immutable properties
+- Leverage discriminated unions for type safety
+- Use type guards for runtime type checking
+- Implement proper null checking
+- Avoid type assertions unless necessary
+
+## Error Handling
+- Create custom error types for domain-specific errors
+- Use Result types for operations that can fail
+- Implement proper error boundaries
+- Use try-catch blocks with typed catch clauses
+- Handle Promise rejections properly
+
+## Patterns
+- Use the Builder pattern for complex object creation
+- Implement the Repository pattern for data access
+- Use the Factory pattern for object creation
+- Leverage dependency injection
+- Use the Module pattern for encapsulation 

package/templates/pc/.cursor/rules/vue.mdc

@@ -0,0 +1,86 @@
+---
+description: Vue.js best practices and patterns for modern web applications
+globs: **/*.vue, **/*.ts, components/**/*
+---
+
+# Vue.js Best Practices
+
+## Component Structure
+- Use Composition API over Options API
+- Keep components small and focused
+- Use proper TypeScript integration
+- Implement proper props validation
+- Use proper emit declarations
+- Keep template logic minimal
+
+## Composition API
+- Use proper ref and reactive
+- Implement proper lifecycle hooks
+- Use composables for reusable logic
+- Keep setup function clean
+- Use proper computed properties
+- Implement proper watchers
+
+## State Management
+- Use Pinia for state management
+- Keep stores modular
+- Use proper state composition
+- Implement proper actions
+- Use proper getters
+- Handle async state properly
+
+## Performance
+- Use proper component lazy loading
+- Implement proper caching
+- Use proper computed properties
+- Avoid unnecessary watchers
+- Use proper v-show vs v-if
+- Implement proper key management
+
+## Routing
+- Use Vue Router properly
+- Implement proper navigation guards
+- Use proper route meta fields
+- Handle route params properly
+- Implement proper lazy loading
+- Use proper navigation methods
+
+## Forms
+- Use v-model properly
+- Implement proper validation
+- Handle form submission properly
+- Show proper loading states
+- Use proper error handling
+- Implement proper form reset
+
+## TypeScript Integration
+- Use proper component type definitions
+- Implement proper prop types
+- Use proper emit declarations
+- Handle proper type inference
+- Use proper composable types
+- Implement proper store types
+
+## Testing
+- Write proper unit tests
+- Implement proper component tests
+- Use Vue Test Utils properly
+- Test composables properly
+- Implement proper mocking
+- Test async operations
+
+## Best Practices
+- Follow Vue style guide
+- Use proper naming conventions
+- Keep components organized
+- Implement proper error handling
+- Use proper event handling
+- Document complex logic
+
+## Build and Tooling
+- Use Vite for development
+- Configure proper build setup
+- Use proper environment variables
+- Implement proper code splitting
+- Use proper asset handling
+- Configure proper optimization 

package/templates/pc/.editorconfig.tpl

@@ -0,0 +1,23 @@
+# http://editorconfig.org
+root = true
+
+[*]
+charset=utf-8
+end_of_line=lf
+insert_final_newline=true
+trim_trailing_whitespace=true
+indent_style=space
+indent_size=2
+
+[{.eslintrc,.babelrc,.stylelintrc,*.json}]
+indent_style=space
+indent_size=2
+
+[*.less]
+indent_style=space
+indent_size=2
+
+[*.{js,jsx,ts,tsx,vue}]
+indent_style=space
+indent_size=2
+

package/templates/pc/.eslintignore

@@ -0,0 +1,13 @@
+node_modules/
+config/
+public/
+src/assets/
+/src/.win
+/src/.win-production
+/src/.win-test
+/.win
+/.win-production
+/.win-test
+/dist
+/dist-zip
+

package/templates/pc/.eslintrc.js

@@ -0,0 +1,9 @@
+// http://eslint.org/docs/user-guide/configuring
+// http://eslint.cn/docs/user-guide/configuring 中文，注意版本是否和官网一致
+module.exports = {
+  extends: [
+    '@winner-fed/eslint-config-win',
+    '@winner-fed/eslint-config-win/vue3',
+    './.eslintrc-auto-import.json'
+  ]
+};

package/templates/pc/.gitignore.tpl

@@ -0,0 +1,54 @@
+/node_modules
+/.env.local
+/.winrc.local.ts
+/config/config.local.ts
+/src/.win
+/src/.win-production
+/src/.win-test
+/src/.huipro
+/.win
+/.win-production
+/.win-test
+/.huipro
+/dist
+/dist-zip
+/.mfsu
+.swc
+components.d.ts
+auto-imports.d.ts
+f2elint-report.json
+
+.DS_Store
+# Log files
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+
+# Editor directories and files
+.idea
+.vscode
+*.suo
+*.ntvs*
+*.njsproj
+*.sln
+*.sw*
+
+# Optional npm cache directory
+.npm
+
+# Optional eslint cache
+.eslintcache
+.eslintrc-auto-import.json
+
+# Optional REPL history
+.node_repl_history
+
+# Output of 'npm pack'
+*.tgz
+
+.project
+.happypack
+.history
+
+/package
+/docker/html

package/templates/pc/.husky/commit-msg

@@ -0,0 +1,6 @@
+#!/usr/bin/env sh
+. "$(dirname -- "$0")/_/husky.sh"
+
+# 以下选择一个即可
+npx --no-install win verify-commit-hs $1
+#npx f2elint commit-msg-scan

package/templates/pc/.husky/pre-commit

@@ -0,0 +1,5 @@
+#!/usr/bin/env sh
+. "$(dirname -- "$0")/_/husky.sh"
+
+npx --no-install lint-staged --quiet
+npx f2elint commit-file-scan

package/templates/pc/.lintstagedrc.tpl

@@ -0,0 +1,5 @@
+{
+  "*.{md,json}": ["prettier --cache --write"],
+  "*.{vue,js,jsx,css,less,scss}": ["win lint --fix", "prettier --cache --write"],
+  "*.ts?(x)": ["win lint --fix", "prettier --cache --parser=typescript --write"]
+}

package/templates/pc/.npmrc.tpl

@@ -0,0 +1,2 @@
+registry={{{ registry }}}
+{{{ extraNpmrc }}}