Recently, a project promotion was carried out within the team, using the Vue
+ Express
stack. After completing the practice, a Standard Operating Procedure (SOP) was produced to guide how to complete specific tasks or activities.
Delete Unused Routes and APIs#
Pre-logic:
- Enable automatic reporting of PV plugin for tracking SDK or automatic reporting of Vue plugin routes. Check if the initial project access is reported correctly.
- Enable API request reporting in the tracking SDK (set in the common request response interceptor).
Unused Routes#
Query the page access records from the tracking data using Druid SQL
for the past three months. Compare the route configuration in the project to identify unused historical routes. Filter out the pages that are explicitly needed and search each one in the project to confirm if there are any internal redirects. After that, confirm the remaining pages with the product and backend teams before deleting them.
Attached is the logic for generating the list of unused routes:
const fs = require('fs')
const path = require('path')
const list = [] as string[]
// Project visited route data
const { data } = require('./data.json')
// Traverse the directory to generate the route list (for projects with conventional routes like nuxt)
const listFile = (dir: string) => {
const arr = fs.readdirSync(dir)
arr.forEach((item: string) => {
const fullpath = path.join(dir, item)
const stats = fs.statSync(fullpath)
if (stats.isDirectory()) {
listFile(fullpath)
} else {
list.push(fullpath)
}
})
return list
}
// Remove the fixed route prefix from the list of project visited routes
const projectVisitedPathList = data.map(item => item.uri.slice('/project_prefix'.length))
// Project full route list
const projectPath = '/your-project-path/src/pages'
const projectPathList = listFile(projectPath)
const startLen = projectPath.length
const indexEndString = '/index.vue'
const allPathList = projectPathList.map(item => {
if (item.endsWith('.vue')) {
if (item.endsWith(indexEndString)) {
// Remove the prefix directory and /index.vue suffix
return item.slice(startLen, -indexEndString.length)
}
// Remove the prefix directory and .vue suffix
return item.slice(startLen, -4)
}
}).filter(item => !!item)
// Filter the full directory route list with the visited route list to get the list of unvisited routes
const unVisitedList = allPathList.filter(item => !projectVisitedPathList.includes(item))
// Add the fixed domain prefix to the unvisited route and write it to a new file
fs.writeFileSync('unVisitedList.json', JSON.stringify(unVisitedList.map(item => 'https://xxx.com/project_prefix' + item)))
Attached is the SQL query:
SELECT
uri,
SUM("count") as "total"
FROM
xxx
WHERE
"__time" >= @start
and "__time" <= @end
and type = '4' -- 4 represents the PV type
and appId = @appId
GROUP BY
uri
ORDER BY
"total" DESC
Unused APIs#
Similarly, query the frontend API access records using Druid SQL
for the past three months. Compare the API route configuration in the project to identify unused historical APIs. Confirm with the backend service API logs before deleting them. The SQL query is similar to the one mentioned above.
Delete Unused Stores#
After deleting unused pages, search the project to check if the corresponding stores are still in use: state
, getters
, mutations
, and actions
. If none of them are used, they can be deleted.
Delete Unused Online Configurations#
After deleting unused routes and stores, check if any related online configurations are still in use. If they are not used, they can be deleted.
Delete Unused Modules and Variables#
Comparison of unused file/variable detection tools:
Tool | Principle | Main Purpose | Remarks |
---|---|---|---|
webpack-deadcode-plugin | Uses the webpack-generated stats file, which contains statistics about modules during webpack compilation These statistics can help developers analyze the dependency graph of the application and optimize the compilation speed | Simple analysis based on webpack, scan results include unused files and variables | Accurate results, wide coverage, recommended to use Generate analysis files as reference and manually confirm deletion (may report false positives when a file is used but the export is not used) |
useless-files-webpack-plugin | Same as above | Simple analysis based on webpack, mainly checks if files are unused, can be configured to automatically delete | Similar detection logic, less functionality compared to the previous tool |
find-unused-exports | Analyzes unused modules in the project based on file dependencies using babel and postcss | Analysis of unused modules exported in files | Can be combined with the first tool for analysis |
ts-prune | TypeScript service provides a useful API: findAllReferences The ts-morph library encapsulates some low-level APIs, including findAllReferences, providing a more concise and user-friendly way to call them ts-prune is based on ts-morph | Analyzes if exported variables in files are used | Less functionality compared to the previous tool, high interference in cases of full exports and Vue file imports Not recommended (future code writing should also avoid full exports) |
- After deleting unused pages, use the webpack-deadcode-plugin tool for scanning and confirmation before deleting (Note: Add an npm script command for continuous analysis and optimization in the future).
- Enable unused variable detection prompts and use the VS Code plugin for assistance in deletion.
- Enable
eslint
rule to checkjs/ts/vue
files for unused variables and show strong error messages for them when committing.
Note: The official{ "rules": { "@typescript-eslint/no-unused-vars": [ "error", { "argsIgnorePattern": "^_" } ], } }
no-unused-vars
rule does not support automatic fixing, manual modification is required.- Enable
tsc
compilation configuration to check for unused variables and unused function parameters.
{ "noUnusedLocals": true, "noUnusedParameters": true }
- When manually modifying, it is recommended to refer to the VS Code prompts first and pay attention to the following cases:
- Do not directly delete unused function parameters if they are not at the end, use the
_
prefix convention. - When there is object destructuring, do not directly delete unused variables as it may cause side effects. Disable the syntax for specific lines (same as the VS Code prompt).
- When the return value of a function is declared but not used, the VS Code prompt will delete the entire declaration + call. Only delete the declaration in this case.
- When an unused parameter in a service method, such as the controller not being passed, can be directly deleted. Otherwise, use the
_
prefix convention.
- Do not directly delete unused function parameters if they are not at the end, use the
- Enable
Monitoring and Alert Configuration#
Common errors are reported using the tracking SDK error plugin. Adjust the observation to a stable level before going live to avoid subsequent interference.
Empty route/API access needs to be newly collected:
- Empty route: Display the 404 error page for access and report the error using the tracking SDK. Communicate with the product team for redirect logic.
- Empty API: Add a fallback match in the backend
Express
Router and log the error.- Reporting logic
controller.on('mounted', () => { resolve(void 0) // Ensure that all routes are mounted before processing setImmediate(() => { app.all('/api/*', function (req: any, res: any) { routeLog.error('route_empty_error', { pathname: req.path, http_method: req.method, referer: req.headers.referer }) res.status(404).json() }) }) })
- Reporting logic
Alert configuration
Module | Function | Alert Strategy (based on project-specific conditions) |
---|---|---|
Vue Error | Global Vue error capture | xx mins sudden increase of xxx |
ReferenceError | Reference error | xx mins sudden increase of xxx |
TypeError | Type error | xx mins sudden increase of xxx |
Empty route access | Report empty route using tracking SDK | xx mins xx occurrences |
Empty API access | Log empty API access | xx mins xx occurrences |
Verification and Deployment#
After verifying that the corresponding monitoring and alert configurations are correct in the pre-production environment, deploy to one machine first and observe for 3-5 days. Once everything is normal, complete the deployment.