Project Historical Logic Offline

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 check js/ts/vue files for unused variables and show strong error messages for them when committing.
```
{
  "rules": {    
      "@typescript-eslint/no-unused-vars": [
          "error",
          {
              "argsIgnorePattern": "^_"
          }
    ],
  }
}
```
Note: The official 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.

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()
      })
    })
  })

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.