Project configuration file analysis method and device and electronic equipment

Abstract

The invention discloses a project configuration file analysis method and device and electronic equipment. The method comprises the steps of reading a source code of an entry file based on an entry file path, and converting the source code of the entry file into an initial abstract syntax tree; extracting a file path imported into the declaration node from the initial abstract syntax tree; based on the initial abstract syntax tree and the absolute path, analyzing a source code of the dependent file, and converting the source code of the dependent file into the abstract syntax tree; constructing a graph data structure based on the abstract syntax tree obtained through analysis; and if the target node of which the file path is completely matched with the absolute path is not found in the graph data structure, determining whether the absolute path is external dependency or not according to whether the absolute path points to an external dependency directory or not. According to the method and the device, the technical problem that the external dependency of the project is difficult to quickly and accurately identify in the project construction and maintenance process due to the uncertainty of an entry file path in the project configuration file and the complexity of a file dependency relationship is solved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a method, apparatus, and electronic device for analyzing project configuration files. Background Technology

[0002] In modern software development, project configuration files are used to define configuration parameters such as build rules, dependency management, and runtime environment. They form the foundation for automated build tools like Webpack, Babel, and Ant Design to understand and execute project build tasks. However, as projects grow larger, the entry file path (i.e., the first file path at which the project begins execution) in the configuration file may become uncertain for various reasons. Furthermore, the dependencies between files become exceptionally complex, especially when relative paths, alias paths, or cross-module dependencies are involved. These dependencies are often scattered across import declarations in multiple files within the project, making the rapid and accurate identification of external dependencies a challenge. External dependencies refer to third-party libraries or frameworks used in the project, typically stored in external directories such as node_modules or linked through content delivery networks. Correctly identifying these external dependencies is crucial for ensuring smooth project builds, optimizing build performance, reducing resource waste, and avoiding potential compatibility issues.

[0003] Currently, most dependency analysis tools or development environments rely on hard-coded rules or simple string matching to resolve dependencies when processing project configuration files. This approach is not only inefficient but also prone to false positives or false negatives, especially when dealing with complex dependency structures or dynamically updated configuration files. Therefore, these technologies struggle to meet the needs of large projects for accurate identification of external dependencies, a need that is particularly urgent when projects iterate frequently and dependencies change constantly.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a method, apparatus, and electronic device for analyzing project configuration files, which at least solves the technical problem of difficulty in quickly and accurately identifying external dependencies of a project during project construction and maintenance, caused by the uncertainty of the entry file path and the complexity of file dependencies in the project configuration file.

[0006] According to one aspect of this application, a method for analyzing a project configuration file is provided, comprising: determining an entry file path from the project configuration file; reading the source code of the entry file based on the entry file path and converting the source code of the entry file into an initial abstract syntax tree, wherein the project configuration file is used to define the project's build configuration parameters; extracting file paths from import declaration nodes in the initial abstract syntax tree and converting relative paths and alias paths in the file paths into absolute paths based on the project root directory, respectively; recursively parsing the source code of dependent files based on the initial abstract syntax tree and the absolute paths, and converting the source code of dependent files into abstract syntax trees; constructing a graph data structure based on the parsed abstract syntax tree, wherein nodes in the graph data structure represent files in the project, and edges represent dependencies between files; if no target node is found in the graph data structure whose file path completely matches the absolute path, determining whether the absolute path is an external dependency based on whether the absolute path points to an external dependency directory.

[0007] Optionally, determining the entry file path from the project configuration file includes: obtaining the project configuration file; reading the project configuration file according to a first priority order, wherein, in the first priority order, the priority of tool-specific configuration is higher than that of project description configuration; extracting the entry configuration field from the project configuration file according to a second priority order, wherein, in the second priority order, the priority of build entry configuration is higher than that of project main entry configuration, and the priority of project main entry configuration is higher than that of default entry file; and determining the entry file path from the project configuration file based on the entry configuration field.

[0008] Optionally, the source code of the entry file is transformed into an initial abstract syntax tree, including: identifying the technology framework type configured in the project configuration file based on project build configuration information and project dependency configuration information, and determining the syntax parser and syntax extension plugin corresponding to the technology framework type; performing lexical and syntactic analysis on the source code of the entry file using the syntax parser and syntax extension plugin to generate the initial abstract syntax tree of the entry file; recursively parsing the source code of the dependency files based on the initial abstract syntax tree and absolute paths, and transforming the source code of the dependency files into abstract syntax trees, including: creating a queue of files to be parsed, and adding the absolute paths of the dependency files extracted from the initial abstract syntax tree as initial elements to the queue of files to be parsed, wherein the queue of files to be parsed... This is used to store the paths of dependency files that need to be parsed in sequence. When the queue of files to be parsed is not empty, the following loop is executed: Extract the dependency file paths from the queue of files to be parsed; use the syntax parser and syntax extension plugins to parse the files corresponding to the dependency file paths, generating an abstract syntax tree for the dependency files; traverse the abstract syntax tree of the dependency files, identify and extract dependency path information from the syntax nodes, where the syntax nodes include at least one of the following: import declaration nodes, export declaration nodes, function declaration nodes, variable declaration nodes, and function call expression nodes; convert the extracted dependency path information into an absolute path based on the project root directory; add the new absolute path to the queue of files to be parsed; continue executing the above loop until the queue of files to be parsed is empty.

[0009] Optionally, based on the parsed abstract syntax tree, a graph data structure is constructed, including: creating an initial graph data structure based on the dependency information in the abstract syntax tree; initializing the state of all nodes in the initial graph data structure to unvisited; and creating access path records and a circular dependency list; traversing the nodes in the initial graph data structure, performing a depth-first traversal for each unvisited node, marking the current node as being accessed during the traversal, and adding the current node to the access path record; obtaining the list of dependent nodes of the current node, and traversing each dependent node in the list; determining whether the state of the dependent node is being accessed; if the dependent node is being accessed, adding the node sequence in the current access path record to the circular dependency list; if the dependent node is unvisited, continuing to recursively traverse the dependent nodes; after completing the traversal of all dependent nodes of the current node, marking the current node as being accessed, and removing the current node from the access path record; continuing the traversal process until all nodes are marked as being accessed; and integrating the circular dependency list into the initial graph data structure to obtain the graph data structure.

[0010] Optionally, the method further includes: identifying redundant files and redundant code in the project configuration file based on the graph data structure, and deleting the redundant files and redundant code.

[0011] Optionally, based on the graph data structure, redundant files and redundant code in the project configuration file are identified, including: collecting dependency information of all nodes in the graph data structure and deduplicating the dependency information to obtain a dependency list; comparing all nodes in the graph data structure with the dependency list and identifying nodes in the graph data structure that do not appear in the dependency list as redundant files; traversing the abstract syntax tree and creating a scope chain, where the scope chain is used to represent the scope hierarchy in the code; collecting declaration information in the scope, finding the reference position of the declaration information, and updating the reference count corresponding to the declaration information according to the reference position, wherein the declaration information includes at least one of the following: variable declaration, function declaration, class declaration, and import declaration; and identifying declaration information with a reference count of zero as redundant code.

[0012] Optionally, determining whether an absolute path is an external dependency based on whether it points to an external dependency directory includes: dividing the absolute path by a directory separator to obtain a sequence of path components; traversing the sequence of path components and comparing each path component with a predefined external dependency directory name; when a component matching the predefined external dependency directory name is found in the sequence of path components, determining that the path structure of the absolute path includes an external dependency directory identifier; and determining that the absolute path is an external dependency if the path structure includes an external dependency directory identifier.

[0013] Optionally, after determining whether an absolute path is an external dependency based on whether it points to an external dependency directory, the method further includes: determining the position of the external dependency package name in the absolute path based on the position of the external dependency directory identifier; extracting the external dependency package name as package identification information from the position in the absolute path, and extracting the version identification information simultaneously when the absolute path includes version information; creating an external dependency node in the graph data structure, wherein the external dependency node includes package identification information, or includes both package identification information and version identification information; and establishing a dependency edge from the source node to the external dependency node.

[0014] Optionally, the method further includes: generating hash values ​​of nodes in the abstract syntax tree; grouping and aggregating nodes based on hash values ​​to obtain a candidate similar node set; calculating the similarity values ​​between nodes using a tree edit distance algorithm for nodes in the candidate similar node set; classifying nodes according to similarity values ​​and generating code refactoring suggestions based on the classification results; and generating a detection report based on similarity values ​​and code refactoring suggestions.

[0015] Optionally, code refactoring suggestions are generated based on the hierarchical classification results, including: for nodes with similarity values ​​greater than or equal to a first threshold, suggestions are generated to extract them as common function modules; for nodes with similarity values ​​greater than or equal to a second threshold and less than the first threshold, suggestions are generated to perform logical merging and refactoring; for nodes with similarity values ​​greater than or equal to a third threshold and less than the second threshold, suggestions are generated to perform abstraction using design patterns.

[0016] Optionally, before generating the hash value of a node in the abstract syntax tree, the method further includes: removing non-semantic logical nodes in the abstract syntax tree, wherein non-semantic logical nodes include comment nodes and whitespace nodes; uniformly replacing string literal nodes in the abstract syntax tree with predefined string identifiers; normalizing numeric literal nodes in the abstract syntax tree to a uniform numeric representation; and uniformizing Boolean literal nodes in the abstract syntax tree to a fixed Boolean value representation.

[0017] According to another aspect of this application, an analysis apparatus for a project configuration file is also provided, comprising: a first determining module, configured to determine the entry file path from the project configuration file, read the source code of the entry file based on the entry file path, and convert the source code of the entry file into an initial abstract syntax tree, wherein the project configuration file is used to define the project's build configuration parameters; a conversion module, configured to extract the file path from the import declaration node in the initial abstract syntax tree, and convert the relative path and alias path in the file path into an absolute path based on the project root directory, respectively; a parsing module, configured to recursively parse the source code of dependent files based on the initial abstract syntax tree and the absolute path, and convert the source code of dependent files into an abstract syntax tree; a building module, configured to build a graph data structure based on the parsed abstract syntax tree, wherein the nodes in the graph data structure are used to represent files in the project, and the edges are used to represent the dependencies between files; and a second determining module, configured to determine whether the absolute path is an external dependency if no target node is found in the graph data structure whose file path completely matches the absolute path, based on whether the absolute path points to an external dependency directory.

[0018] According to another aspect of this application, a non-volatile storage medium is also provided, the storage medium including a stored program, wherein the program, when running, controls the device where the storage medium is located to execute the above-mentioned project configuration file analysis method.

[0019] According to another aspect of this application, an electronic device is also provided, comprising: a memory and a processor, the processor being configured to run a program stored in the memory, wherein the program, when running, executes the analysis method of the above-described project configuration file.

[0020] According to another aspect of this application, a computer program is also provided, wherein when the computer program is executed by a processor, it implements the above-described method for analyzing the project configuration file.

[0021] According to another aspect of this application, a computer program product is also provided, comprising a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, which, when executed by a processor, implements the above-described method for analyzing the project configuration file.

[0022] In this application, the entry file path is determined from the project configuration file. Based on this path, the source code of the entry file is read and transformed into an initial abstract syntax tree (API). The project configuration file defines the project's build configuration parameters. File paths are extracted from import declaration nodes within the API, and relative and alias paths are converted into absolute paths based on the project root directory. Based on the API and absolute paths, the source code of dependent files is recursively parsed and transformed into APIs. A graph data structure is constructed based on the parsed APIs, where nodes represent files in the project and edges represent dependencies between files. If no target node matching the absolute path is found in the graph data structure, the absolute path is used to determine if it is an external dependency. This approach automatically identifies and manages project dependencies, improving project build and maintenance efficiency and reducing resource waste. It also solves the problem of difficulty in quickly and accurately identifying external dependencies during project build and maintenance due to the uncertainty of the entry file path in the project configuration file and the complexity of file dependencies. Attached Figure Description

[0023] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0024] Figure 1 This is a flowchart of a project configuration file analysis method according to an embodiment of this application;

[0025] Figure 2 This is a flowchart of a method for detecting circular dependencies according to an embodiment of this application;

[0026] Figure 3 This is a flowchart of a method for detecting redundant files according to an embodiment of this application;

[0027] Figure 4This is a flowchart of a method for detecting redundant code according to an embodiment of this application;

[0028] Figure 5 This is a flowchart of a similar code detection method according to an embodiment of this application;

[0029] Figure 6 This is a structural diagram of a project configuration file analysis device according to an embodiment of this application;

[0030] Figure 7 This is a hardware structure block diagram of a computer terminal for a project configuration file analysis method according to an embodiment of this application. Detailed Implementation

[0031] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0032] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0033] According to an embodiment of this application, a method embodiment for analyzing a project configuration file is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0034] Figure 1 This is a flowchart of a project configuration file analysis method according to an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:

[0035] Step S101: Determine the entry file path from the project configuration file, read the source code of the entry file based on the entry file path, and convert the source code of the entry file into an initial abstract syntax tree. The project configuration file is used to define the project's build configuration parameters.

[0036] The project configuration file can include, but is not limited to, webpack.config.js, babel.config.js, or other custom configuration files. This file specifies parameters such as the project's build rules, dependency management, and runtime environment. The path information of the entry file is extracted from the project configuration file according to a preset priority order. This priority order defines the logic that tool-specific configurations take precedence over project description configurations, build entry configurations take precedence over the project's main entry configuration, and the project's main entry configuration takes precedence over the default entry file. Through this process, the starting point of the project build, i.e., the entry file path, can be determined. Subsequently, based on this path, the source code of the entry file is read, and lexical and syntactic analysis is performed using the corresponding parser and extension plugins to generate the initial abstract syntax tree of the entry file.

[0037] Step S102: Extract the file path from the import declaration node from the initial abstract syntax tree, and convert the relative path and alias path in the file path into absolute paths based on the project root directory.

[0038] From the initial abstract syntax tree generated in step S101, identify and extract file path information from all import declaration nodes. This file path information can be given in the form of relative paths or aliases, and needs to be further converted to absolute paths based on the project root directory for subsequent dependency resolution and unified management. The path conversion process ensures the uniqueness and standardization of all dependency file paths.

[0039] Step S103: Based on the initial abstract syntax tree and absolute path, recursively parse the source code of the dependent files and transform the source code of the dependent files into an abstract syntax tree.

[0040] For example, a queue of files to be parsed can be created, with the absolute paths of dependent files extracted from the initial abstract syntax tree (AST) added as initial elements. As long as the queue is not empty, a dependent file path is retrieved, its source code is parsed using a parser and extension plugins, generating the corresponding AST, and further extracting new dependent path information from these ASTs, converting them to absolute paths, and adding them to the queue. This process is repeated until the queue is empty, ensuring that the source code of all dependent files in the project has been parsed and transformed into an AST, creating a comprehensive dependency graph.

[0041] Step S104: Based on the parsed abstract syntax tree, construct a graph data structure, where nodes in the graph data structure represent files in the project, and edges represent dependencies between files.

[0042] Step S104: Based on the abstract syntax tree parsed in step S103, a graph data structure is created. In this structure, the root node of each abstract syntax tree represents a project file, and the edges in the graph represent dependencies between files—that is, one file directly or indirectly references another. By traversing the graph data structure using algorithms such as depth-first search or breadth-first search, circular dependencies, direct dependencies, and indirect dependencies in the file hierarchy can be identified, providing a clear visual and computational model for subsequent dependency analysis and management.

[0043] Step S105: If no target node whose file path and absolute path completely match are found in the graph data structure, determine whether the absolute path is an external dependency based on whether the absolute path points to an external dependency directory.

[0044] During the construction of the graph data structure, for each absolute path for which no matching node is found in the graph, its path structure is analyzed to determine whether the path points to an external dependency directory. Specifically, the absolute path is split by a directory separator, resulting in a series of path components. These components are then traversed and compared with predefined external dependency directory names. If any component matches a predefined external dependency directory name, such as `node_modules` or a third-party CDN link, then the absolute path is determined to contain an external dependency directory identifier, and further analysis is performed to determine if it is an external dependency. This mechanism ensures that all external dependencies defined in the project configuration file are accurately identified, thereby avoiding the loading of unnecessary external resources during project building and maintenance, optimizing the build process, and improving build efficiency. Furthermore, by identifying external dependencies, this application can also provide more accurate information for project dependency upgrades, version management, and optimization.

[0045] The above steps involve determining the entry file path from the project configuration file, reading the source code of the entry file based on the entry file path, and converting the source code into an initial abstract syntax tree (API). The project configuration file defines the project's build configuration parameters. File paths are extracted from import declaration nodes in the API, and relative and alias paths are converted into absolute paths based on the project root directory. Based on the API and absolute paths, the source code of dependent files is recursively parsed and converted into APIs. A graph data structure is constructed based on the parsed API, where nodes represent files in the project and edges represent dependencies between files. If no target node is found in the graph data structure whose file path completely matches the absolute path, the absolute path is used to determine if it is an external dependency. This approach automatically identifies and manages project dependencies, thereby improving project build and maintenance efficiency and reducing resource waste.

[0046] The following are Figure 1 The steps shown are illustrated and explained by way of example.

[0047] According to some optional embodiments of this application, the entry file path can be determined from the project configuration file by the following method: obtaining the project configuration file, reading the project configuration file in a first priority order, wherein, in the first priority order, the priority of tool-specific configuration is higher than that of project description configuration; extracting the entry configuration field from the project configuration file in a second priority order, wherein, in the second priority order, the priority of build entry configuration is higher than that of project main entry configuration, and the priority of project main entry configuration is higher than that of default entry file; and determining the entry file path from the project configuration file based on the entry configuration field.

[0048] Tool-specific configurations are configuration files required by specific build tools or development frameworks, such as webpack.config.js for Webpack and .babelrc for Babel; project description configurations are description files for the project itself, such as package.json, which include basic project information, dependencies, and build scripts.

[0049] In this embodiment, the project configuration files are first read according to the first priority order. In this first priority order, tool-specific configurations have a higher priority. This means that if a definition of the entry file path is found in a tool-specific configuration file, that definition will be adopted first, even if the same or similar configuration exists in the project description configuration file; it will be overridden by the tool-specific configuration.

[0050] Then, following the second priority order, the entry configuration fields are extracted from the project configuration file. In this second priority order, the build entry configuration has the highest priority, followed by the project main entry configuration, and finally the default entry file. The build entry configuration refers to the entry file path directly specified in the tool's dedicated configuration file, such as the `entry` field in the Webpack configuration. The project main entry configuration refers to the `main` field defined in `package.json`, which indicates the project's main entry file. The default entry file is the first executable file that the build tool looks for based on its default behavior when no explicit configuration is provided, such as `src / index.js` or `main.js`.

[0051] For example, in a typical React project, the entry configuration in webpack.config.js could be: markdown / / Tool-specific configuration: Webpack-defined entry point entry: '. / src / index.js'.

[0052] In package.json, the main entry point configuration for the project might be: markdown / / Project description configuration: the main field in package.json "main": "app.js".

[0053] Based on priority principles, if an entry file is defined in `webpack.config.js`, then `. / src / index.js` will be used directly as the entry point, even if a main entry file is specified in `package.json`. If no entry file is defined in `webpack.config.js`, then the `main` field in `package.json` needs to be checked, and `app.js` will be used as the entry file. If no entry file definition is found in any configuration file, the default entry file will be used, such as `src / index.js` or a file with a similar name.

[0054] When determining the entry file path based on the entry configuration fields, each configuration file needs to be checked one by one, starting with the tool-specific configurations, then the project description configurations, and finally considering the default settings. This logic ensures that at the start of the project build, the first source code file (the entry file) is read and processed using the optimal path settings, thus effectively initiating the entire build process and avoiding build failures or resource waste caused by uncertain entry file paths.

[0055] According to some alternative embodiments of this application, the source code of the entry file can be transformed into an initial abstract syntax tree (API). This can be achieved by: identifying the technology framework type configured in the project configuration file based on project build configuration information and project dependency configuration information, and determining the corresponding parser and syntax extension plugin for each technology framework type; performing lexical and syntactic analysis on the source code of the entry file using the parser and syntax extension plugin to generate the initial API; and recursively parsing the source code of dependent files based on the initial API and absolute paths, and transforming the source code of dependent files into APIs, including: creating a queue of files to be parsed, and adding the absolute paths of dependent files extracted from the initial API as initial elements to the queue of files to be parsed. The queue of files to be parsed stores the paths of dependent files that need to be parsed in sequence. When the queue is not empty, the following loop is executed: Dependency file paths are extracted from the queue; the files corresponding to the dependency file paths are parsed using a syntax parser and syntax extension plugins to generate an abstract syntax tree (AST) for the dependency files; the AST is traversed to identify and extract dependency path information from syntax nodes, where syntax nodes include at least one of the following: import declaration nodes, export declaration nodes, function declaration nodes, variable declaration nodes, and function call expression nodes; the extracted dependency path information is converted into an absolute path based on the project root directory; the new absolute path is added to the queue of files to be parsed; the above loop continues until the queue of files to be parsed is empty.

[0056] In this summary, the first step is to identify the technology framework type specified in the project configuration file. This technology framework type can be a front-end framework such as React, Vue, or Angular, or a back-end framework such as Express, Django, or Flask, as well as other specific libraries or tools that may be used in the project. These frameworks and libraries can be identified by parsing configuration files, such as the `dependencies` field in `package.json` or the `webpack.config.js` configuration file for a specific build tool like Webpack. After identifying the technology framework type, the matching parser and necessary syntax extension plugins can be determined. The parser is used for lexical analysis and syntax analysis, while the syntax extension plugins are used to handle framework-specific syntactic structures or features.

[0057] For example, in a project using the React framework, the project configuration file might contain information about React dependencies and the Webpack build tool's configuration, specifying particular parsers and plugins like babel-loader for handling ES6 syntax and React's JSX syntax. After identifying the project's technology framework as React, the algorithm selects a parser that matches React, namely the Babel parser, and loads the corresponding syntax extension plugins, such as `@babel / plugin-transform-react-jsx`, to ensure the parser can correctly handle JSX syntax.

[0058] Next, a defined parser and necessary syntax extension plugins are used to perform lexical and syntactic analysis on the source code of the entry file. This process transforms the source code into a computer-understandable structure, generating the initial abstract syntax tree (AST) of the entry file. An AST is a tree-like structure used to represent the syntactic structure of a program, where the nodes represent elements in the syntactic structure, such as variables, functions, and expressions, and the edges represent the relationships between these elements.

[0059] Then, based on the initial abstract syntax tree (API) and absolute paths, the source code of dependent files is recursively parsed. A queue of files to be parsed is created, and the absolute paths of dependent files extracted from the initial API are added to the queue as initial elements. While the queue is not empty, a loop processing phase begins: a path to a dependent file is extracted from the queue, and the source code of the dependent file is parsed using the established parser and plugins to generate an API for the dependent file. The API for the dependent file is traversed, identifying and extracting dependency path information from syntax nodes. These nodes include, but are not limited to, import declaration nodes, export declaration nodes, function declaration nodes, variable declaration nodes, and function call expression nodes. The identified dependency path information is converted into absolute paths based on the project root directory to ensure path consistency and clarity. The newly obtained absolute paths are added to the queue of files to be parsed for subsequent file parsing. This loop continues until the queue of files to be parsed is empty, meaning that all files directly or indirectly dependent on by the project have been parsed and converted into APIs, constructing a complete project dependency graph. This process not only improves the accuracy and efficiency of dependency parsing but also helps developers understand the project dependency structure, facilitating more refined code management and optimization.

[0060] In some optional embodiments of this application, the graph data structure can be constructed based on the parsed abstract syntax tree as follows: Based on the dependency information in the abstract syntax tree, an initial graph data structure is created. All nodes in the initial graph data structure are initialized to an unvisited state, and access path records and a circular dependency list are created. The nodes in the initial graph data structure are traversed. For each unvisited node, a depth-first traversal is performed. During the traversal, the current node is marked as being accessed, and the current node is added to the access path record. The list of dependent nodes of the current node is obtained, and each dependent node in the list is traversed. It is determined whether the state of the dependent node is being accessed. If the dependent node is being accessed, the node sequence in the current access path record is added to the circular dependency list. If the dependent node is unvisited, the dependent nodes are recursively traversed. After traversing all dependent nodes of the current node, the current node is marked as being accessed, and the current node is removed from the access path record. The traversal process continues until all nodes are marked as being accessed. The circular dependency list is integrated into the initial graph data structure to obtain the graph data structure.

[0061] In this embodiment, an initial graph data structure needs to be created first based on all the transformed ASTs. In the initial graph data structure, each node represents a source code file, and edges represent dependencies between files. Initially, all nodes are set to "unvisited" because traversal of these nodes has not yet begun. Simultaneously, a visit path record is created to store the visit history of nodes during the current traversal, along with a circular dependency list to record any circular dependencies discovered during the traversal.

[0062] For each node in the graph data structure, for each node currently in the "unvisited" state, first mark it as "visiting" and add it to the access path record to track the traversal path. Then, obtain the list of dependent nodes in the AST corresponding to that node, i.e., other files directly or indirectly referenced by that file, and then traverse each dependent node in the list.

[0063] For dependent nodes, check if their status is marked as "accessing". If a dependent node is being accessed, i.e., its status is "accessing", it indicates a circular dependency—that is, one file depends on another file, and the latter in turn depends on the former. In this case, the entire sequence of nodes in the current access path record is added to the circular dependency list to record these files that form a circular relationship.

[0064] If a dependent node has not yet been visited (i.e., its state is still "unvisited"), continue performing a depth-first traversal, recursively exploring the dependencies of dependent nodes until all dependent nodes have been visited. During the traversal, when all dependencies of a node have been visited (i.e., the traversal is complete), the node's state will change from "visiting" to "visited," and the node will be removed from the access path record, indicating that it has completed the traversal.

[0065] The traversal process continues until all nodes in the graph are marked as "visited," meaning all files in the project and their dependencies have been traversed. At this point, the list of circular dependencies is integrated into the graph data structure, generating the final graph data structure. This final graph data structure clearly displays all files in the project and their dependencies, including normal and circular dependencies. This is crucial for subsequent dependency optimization, refactoring suggestion generation, and code quality checks. Through this mechanism, developers can quickly locate and resolve circular dependency issues, avoiding build failures or runtime exceptions. It also helps in understanding the overall dependency hierarchy and structure of the project, improving its sustainability and maintainability.

[0066] For example, in a project, suppose there are three files: A.js, B.js, and C.js. A.js imports B.js and C.js, and B.js imports C.js. During traversal, when starting from A.js and accessing B.js, and finding that B.js depends on C.js, C.js will be marked as "under access" and added to the path record. If, while traversing C.js, you try to access B.js again, you will find that B.js is already in the "under access" state, and the path A->B->C->B will be added to the circular dependency list. After the traversal is complete, the state of all nodes will be updated. The graph data structure will reflect the file dependencies in the project, including normal dependencies and circular dependencies, providing strong data support for project health analysis, refactoring suggestions, and maintenance.

[0067] As some optional embodiments of this application, the analysis method for project configuration files further includes the following steps: based on a graph data structure, identifying redundant files and redundant code in the project configuration file, and deleting the redundant files and redundant code.

[0068] Specifically, based on the graph data structure, identifying redundant files and code in the project configuration file can be achieved through the following methods: Collect dependency information for all nodes in the graph data structure and deduplicate the dependency information to obtain a dependency list; compare all nodes in the graph data structure with the dependency list, and identify nodes in the graph data structure that do not appear in the dependency list as redundant files; traverse the abstract syntax tree and create a scope chain, where the scope chain represents the scope hierarchy in the code; collect declaration information in the scopes, locate the reference positions of the declaration information, and update the reference counts corresponding to the declaration information based on the reference positions, where the declaration information includes at least one of the following: variable declarations, function declarations, class declarations, and import declarations; identify declaration information with a reference count of zero as redundant code.

[0069] In this embodiment, the graph constructed from the project files is first traversed, each edge (i.e., the dependencies between files) is extracted, and the dependency information is summarized. The dependency information includes direct and indirect references between files, such as A.js depending on B.js, B.js depending on C.js, etc. After collection, the dependency information is deduplicated to generate a dependency list, ensuring that each dependency is recorded only once, thereby avoiding duplicate dependency calculations.

[0070] Next, the generated dependency list is compared with all nodes in the graph data structure. This comparison identifies nodes not appearing in the dependency list. Since no dependencies point to these nodes, they are considered redundant files because they will not be referenced or needed by other files during the project build process. Redundant files not only increase build time and space overhead but can also lead to version control issues and documentation inconsistencies. Therefore, identifying and deleting these files helps optimize the project structure and reduce unnecessary resource consumption.

[0071] While identifying redundant files, it's also crucial to focus on recognizing redundant code, which can be achieved through traversing and analyzing the Abstract Syntax Tree (AST). During AST traversal, a scope chain is created to represent the hierarchical structure of scopes in the code. This scope chain reflects the visibility and lifecycle of variables, functions, and other declarations, such as local scopes within functions and global scopes at the file level. During scope chain traversal, every declaration is collected and recorded, including variable declarations, function declarations, class declarations, and import declarations. Then, the reference location of each declaration in the code is located. If a declaration is referenced, its reference count is incremented accordingly.

[0072] Declarations with a reference count of zero—that is, code snippets that are not referenced by any other code in the entire project—can be identified as redundant code. Redundant code also increases project complexity and maintenance difficulty. Identifying and removing such code helps improve code quality and readability, and simplifies project structure.

[0073] For example, if a file named D.js in a project is never depended on by any other file, it won't appear in the dependency list and can therefore be marked as redundant. Similarly, if a file named X.js contains a function named unusedFunction, but it's found to be never called during the traversal of the project's scope chain and reference count updates, then this function can be considered redundant code. Identifying and removing redundant files and code is crucial for streamlining projects, reducing build time and resource consumption, and improving code quality and maintainability.

[0074] By following the steps above, we can not only effectively identify and handle redundant files in the project, but also delve into the code level to identify and eliminate redundant code, thereby ensuring the project's efficiency and cleanliness. This process not only reduces unnecessary resource consumption during the build process but also improves code readability and maintainability.

[0075] In some optional embodiments of this application, determining whether an absolute path is an external dependency based on whether it points to an external dependency directory can be achieved by the following method: dividing the absolute path by a directory separator to obtain a sequence of path components; traversing the sequence of path components and comparing each path component with a predefined external dependency directory name; when a component matching the predefined external dependency directory name is found in the sequence of path components, it is determined that the path structure of the absolute path includes an external dependency directory identifier; if the path structure of the absolute path includes an external dependency directory identifier, the absolute path is determined to be an external dependency.

[0076] In this embodiment, the absolute path is split by a directory separator. The purpose is to decompose the complete file path into a series of directory and filename components to facilitate subsequent directory name matching and identification. An absolute path is a path that starts from the root directory and points to a specific location in the file system. Its format is, for example, / root / directory1 / directory2 / filename.

[0077] The process iterates through the sequence of path components separated by directory separators. Each component is examined to identify whether it contains a predefined external dependency directory name. These predefined external dependency directory names can be common directories for storing third-party libraries or modules in a project, such as `node_modules`, `vendor`, or `lib`. The comparison process checks each component of the path one by one to see if it matches an external dependency directory name.

[0078] When a component matching a predefined external dependency directory name is found in the path component sequence, it indicates that the current path is pointing to or has passed through the location where the external dependency is stored. At this point, an external dependency directory identifier is marked or recorded in the path structure; this is a key indicator for identifying whether a path points to an external dependency. For example, if `node_modules` is found while traversing ` / project / src / components / node_modules / react`, then the absolute path ` / project / src / components / node_modules / react` will contain the external dependency directory identifier `node_modules`.

[0079] If an absolute path includes an external dependency directory identifier, then that absolute path is considered an external dependency. This means that if a predefined external dependency directory name is detected in the path, it can be concluded that the path points to a third-party library or module that the project depends on, rather than the project's own source code files.

[0080] For example, if an absolute path is ` / home / user / project / node_modules / react / index.js`, then by examining the path's component sequence ['home', 'user', 'project', 'node_modules', 'react', 'index.js'] and comparing it with the predefined external dependency directory name `node_modules`, we can determine that `node_modules` exists in the path, and thus conclude that the entire path ` / home / user / project / node_modules / react / index.js` points to an external dependency. This identification process is crucial for building the project's dependency graph and for subsequent dependency management and code optimization.

[0081] Furthermore, after determining whether an absolute path is an external dependency based on whether it points to an external dependency directory, the following steps can be performed: Based on the position of the external dependency directory identifier in the absolute path, determine the position of the external dependency package name in the absolute path; extract the external dependency package name from the position in the absolute path as package identification information, and extract the version identification information simultaneously if the absolute path includes version information; create an external dependency node in the graph data structure, wherein the external dependency node includes package identification information, or includes both package identification information and version identification information; establish a dependency edge from the source node to the external dependency node.

[0082] This embodiment first searches backwards from the element containing the external dependency directory identifier until it encounters the next level identifier. For example, in the path / project / node_modules / react / index.js, if node_modules is confirmed to be the external dependency directory identifier, the search starts from the first element after node_modules and continues until the last element before index.js, i.e., react, which is the exact location of the external dependency package name part.

[0083] The package name portion extracted from the absolute path becomes the package identifier, which forms the basis for subsequent dependency management and version control. In some cases, especially in modern software engineering practices, the package identifier can also include version information. For example, in the path ` / project / node_modules / react@16.13.1 / index.js`, `react@16.13.1` is the complete package identifier, specifying not only the package name `react` but also the specific version `16.13.1`. Version information is crucial for ensuring accurate matching of project dependencies, especially when external dependencies have multiple versions, and different versions may have incompatible changes.

[0084] Create external dependency nodes in the graph data structure to ensure that each external dependency package has a corresponding graph node for accurate representation when building the project dependency graph. External dependency nodes contain package identifier information and, if applicable, version identifier information to precisely identify each external dependency. For example, for react@16.13.1, an external dependency node named react@16.13.1 will be created in the graph.

[0085] Establishing dependency edges from source nodes to external dependent nodes specifically involves explicitly representing the relationship where a project file depends on a certain external package in the graph data structure. Whenever the source code of a project file contains a reference to an external package, an edge needs to be created in the graph from the source file node to the corresponding external dependent node. For example, if the App.js file imports react, then in the graph, the App.js node will have an edge pointing to the react@16.13.1 external dependent node, clearly depicting the dependency relationship.

[0086] The steps described above, by accurately identifying and recording external dependencies, can effectively avoid errors caused by dependency issues during project construction or runtime. They also facilitate tracking and managing the versions of various dependency packages used in the project, ensuring smooth project operation and long-term maintenance.

[0087] In some optional embodiments, the analysis method for the project configuration file further includes the following steps: generating hash values ​​of nodes in the abstract syntax tree; grouping and aggregating nodes based on hash values ​​to obtain a set of candidate similar nodes; calculating the similarity values ​​between nodes using a tree edit distance algorithm for nodes in the set of candidate similar nodes; classifying nodes according to similarity values ​​and generating code refactoring suggestions based on the classification results; and generating a detection report based on similarity values ​​and code refactoring suggestions.

[0088] Specifically, generating code refactoring suggestions based on the hierarchical classification results can be achieved as follows: for nodes with similarity values ​​greater than or equal to the first threshold, generate suggestions to extract them as common function modules; for nodes with similarity values ​​greater than or equal to the second threshold and less than the first threshold, generate suggestions to perform logical merging and refactoring; for nodes with similarity values ​​greater than or equal to the third threshold and less than the second threshold, generate suggestions to use design patterns for abstraction.

[0089] In this embodiment, starting from the root node of the AST, a hash value is recursively calculated for each child node. Factors such as the node's type, name, parameters, return value type, and the connection method of the child nodes are comprehensively considered to form a digital fingerprint that uniquely identifies the node. Generating hash values ​​ensures that even in large and complex ASTs, similar code structures can be quickly identified and matched without line-by-line comparison, thus improving efficiency.

[0090] The purpose of grouping and aggregating nodes based on the generated hash values ​​is to identify and collect all nodes with the same or similar hash values, forming a candidate set of similar nodes. By grouping nodes with the same hash value together, a large number of potentially duplicated or highly similar code snippets can be quickly filtered out. This is an important step in finding refactoring opportunities, because in large projects, similar code may be scattered across multiple files or modules, and manually searching for it is both time-consuming and error-prone.

[0091] For each node in the candidate set of similar nodes, the tree edit distance algorithm is used to calculate the similarity score between the nodes. Tree edit distance measures the minimum number of edit operations required to achieve structural consistency between two trees (in this case, subtrees of an abstract syntax tree). Edit operations can include inserting, deleting, or modifying node attributes. By using the tree edit distance algorithm, the structural and semantic proximity of two nodes can be calculated, thus quantifying their similarity.

[0092] Nodes are categorized based on similarity scores to differentiate between different levels of code duplication or similarity, thus guiding more precise refactoring suggestions. For example, nodes with similarity scores above a high threshold (such as the first threshold) can be classified as code blocks that can be merged into a common function module; nodes with lower similarity scores but still within a certain range (such as the second threshold) can be suggested for logical merging or refactoring to reduce code redundancy; and nodes with very low similarity scores (such as below the third threshold) can be considered independent logical units without requiring special refactoring actions.

[0093] Based on the classification results, specific code refactoring suggestions are generated. These suggestions may include, but are not limited to: for highly similar code snippets, suggesting the creation of a shared function or class; for moderately similar code, recommending logical refactoring, such as using the factory pattern or strategy pattern; and for low-similarity code, emphasizing preserving the original state or making minor adjustments to maintain the code's specificity and functionality.

[0094] Based on the similarity score and refactoring suggestions, a detailed detection report is generated. The report lists all identified similar code snippets, including their file location, original code content, similarity score, and specific refactoring suggestions for each snippet. This report is a valuable tool for development teams, helping members quickly locate potential code duplication, assess the feasibility of refactoring, optimize code structure, and improve project efficiency and code quality.

[0095] Optionally, before generating the hash values ​​of nodes in the abstract syntax tree, the following steps may also be performed: removing non-semantic logical nodes in the abstract syntax tree, where non-semantic logical nodes include comment nodes and whitespace nodes; uniformly replacing string literal nodes in the abstract syntax tree with predefined string identifiers; normalizing numeric literal nodes in the abstract syntax tree to a unified numeric representation; and uniformizing Boolean literal nodes in the abstract syntax tree to a fixed Boolean value representation.

[0096] Before processing the Abstract Syntax Tree (AST) for deeper code analysis and refactoring suggestion generation, it needs to be preprocessed to optimize its structure and ensure more accurate identification of code similarities and dependencies. The preprocessing process includes four main steps:

[0097] First, non-semantic logic nodes are removed. These nodes do not participate in code execution but can affect readability; examples include comment nodes and whitespace nodes. Comment nodes contain explanatory text added by the developer, while whitespace nodes include spaces, tabs, and newlines. These nodes are unnecessary for code similarity or dependency analysis; removing them reduces processing load and improves analysis speed and efficiency.

[0098] Secondly, string literal nodes in the Abstract Syntax Tree (AST) are uniformly replaced with predefined string identifiers. String literal nodes represent string constants in the code, such as string parameters or variable initialization values. Replacing them with predefined identifiers helps avoid inaccurate code structure similarity calculations due to differences in specific string content. This is because the same string or strings with similar functions in different locations may behave differently in the code, but their logical meaning is the same or similar. This standardization process ensures that the similarity of code logical structure can be identified more accurately, rather than being influenced by specific text content.

[0099] Next, the numeric literal nodes in the abstract syntax tree are normalized, converting them into a uniform numeric representation. Numeric literal nodes represent numeric constants in the code. Normalization ensures that even if the numerical formats or precisions differ, code snippets with equal or logically equivalent values ​​can be correctly identified as similar. For example, the numbers 10, 10.0, or 1e1 are mathematically equivalent, but might be considered different nodes in the unprocessed AST.

[0100] Finally, Boolean literal nodes in the abstract syntax tree are uniformly represented as fixed Boolean values, which can be either true or false. Boolean literal nodes represent Boolean constants in the code, used for logical judgments and flow control. This unified Boolean value representation also avoids misjudgments of structural similarity due to differences in the specific representation of Boolean values, ensuring that the algorithm can correctly identify logically equivalent code segments.

[0101] The above preprocessing operations can not only reduce the complexity of the AST and improve the efficiency of subsequent analysis and refactoring suggestion generation, but also ensure that when identifying code similarities and dependencies, we can focus more on the logical structure and function of the code, rather than being affected by the details of specific text content, numerical format or Boolean value representation.

[0102] This application also provides a method for analyzing project configuration files, which specifically includes the following steps.

[0103] Step S1, AST parsing.

[0104] Step S11, entry file location. The project configuration files are read in the following priority order: webpack.config.js → vite.config.ts / js → package.json. Following this priority: webpack's entry configuration → vite's build.rollupOptions.input configuration → package.json's main field → the default index.js / index.ts, relevant configuration fields are extracted. Path aliases (such as @ / , ~ / ) in the configuration are parsed, and relative paths are converted to absolute paths based on the project root directory. The existence of the parsed entry file is then checked.

[0105] Step S12, Parser Judgment. Different parsers are used for different frameworks (@babel / preset-react, @vue / compiler-dom, @babel / preset-typescript). The loader configuration in webpack or vite is analyzed, and the existence of a tsconfig.json file in the package.json is checked to confirm if it's a TypeScript project. File extensions are combined with the read file content; for example, if React-related imports are present (e.g., `import React from 'react'`), JSX syntax features are checked for. <component>Tags are React files; they recognize Vue-specific syntax, such as... <template> 、 <script>、<style>标签则是Vue文件；如果包含TypeScript特有的语法，如类型注解、接口定义等则是ts文件。

[0106] 步骤S13，抽象语法树构建。对项目入口文件进行词法分析，使用对应的Babel解析器生成入口文件的AST；同时创建待解析队列，用于存储后续需要解析的依赖文件路径。基于解析器判断结果，使用相应的Babel解析器及扩展插件解析文件内容；生成tokens并构建关键AST节点：ImportDeclaration（导入声明）、ExportDeclaration（导出声明）、FunctionDeclaration（函数声明）、VariableDeclaration（变量声明）、CallExpression（函数调用）；同时处理相对路径识别和别名转换。在解析过程中持续收集import路径，将新发现的依赖文件路径添加到待解析队列中；对于node_modules中的外部模块，仅记录模块名称和版本信息。按照先进先出的方式循环解析依赖文件，确保每个依赖都被完整处理；持续执行解析流程直到待解析队列为空，保证项目中所有相关依赖关系都被正确识别和构建到AST中。

[0107] 图2是根据本申请实施例的一种循环依赖检测的方法流程图，如图2所示，循环依赖检测可以通过如下步骤实现。

[0108] 首先，初始化整个图数据结构中的所有节点状态为"未访问”，并创建一个访问路径记录用于跟踪当前遍历过程中的节点顺序，以及一个循环依赖列表用来保存检测到的循环依赖路径。

[0109] 其次，开始遍历图数据结构中的每一个节点。对于每一个"未访问”状态的节点，将其状态改为"访问中”以表示正在对该节点进行处理，进而将此节点添加到访问路径记录中，记录其在遍历过程中的位置。

[0110] 然后，获取当前节点的依赖节点列表，即那些当前节点直接或间接引用的其他节点。遍历这个依赖节点列表，对每一个依赖节点执行以下检查：

[0111] 如果依赖节点的状态也是"访问中”，这意味着在遍历过程中遇到了之前已经开始但尚未完成遍历的节点，形成了一个节点循环。此时，将当前访问路径记录中涉及的节点序列添加到循环依赖列表中，记录下这一循环依赖情况。另一方面，如果依赖节点的状态仍然是"未访问”，那么递归地对该依赖节点执行相同的遍历和检查过程，即继续深入依赖节点的依赖结构，直到遍历完整个依赖链。

[0112] 在完成当前节点的所有依赖节点的遍历后，将当前节点的状态从"访问中”更新为"已访问”，意味着该节点及其所有依赖节点都已经被成功遍历。此外，当前节点也会从访问路径记录中移除，表示该节点的遍历路径已完成，不再参与后续的循环检测。

[0113] 遍历和检测过程会持续进行，直到图数据结构中的所有节点都被标记为"已访问”状态。此时，循环依赖列表中已经包含了项目中所有检测到的循环依赖路径，每一条路径记录都表示了相互依赖的节点序列。将循环依赖列表整合到图数据结构中，生成最终图数据结构。

[0114] 步骤S2，依赖分析。

[0115] 步骤S21，循环依赖检测。 所有节点设置初始状态为"未访问"，创建空的循环依赖列表用于记录检测结果。遍历所有未访问节点，对每个节点启动DFS搜索。将当前节点标记为"访问中"状态并加入访问路径栈，然后递归访问其所有依赖节点。在递归过程中，如果发现依赖节点已处于"访问中"状态，说明形成了从该依赖节点回到自身的环路，此时记录完整的循环路径到结果列表中。节点的所有依赖都处理完毕后，将节点状态更新为"已访问"并从访问路径中移除。所有节点都被标记为"已访问"状态时，结束并返回所有循环依赖路径列表。

[0116] 步骤S22，依赖关系图构建基于收集到的AST树，采用有向图数据结构来表示项目的完整依赖网络，结构中每个节点代表一个文件，每一条边代表一个依赖关系。先创建所有文件节点，然后根据AST分析结果逐步添加依赖边。节点包含以下信息：节点ID、节点名称、文件路径、文件名称、文件大小、AST信息、依赖关系等等，其中AST信息中的关键节点信息是在语法树构建阶段已经创建并且记录的： ImportDeclaration（导入声明），ExportDeclaration（导出声明），FunctionDeclaration（函数声明），VariableDeclaration（变量声明），CallExpression（函数调用）。基于AST分析结果构建边关系，边信息涵盖静态依赖、动态依赖和样式依赖等多种类型，通过路径解析将相对路径和别名路径转换为绝对路径后在图中查找对应的目标节点。当目标节点不存在时，检查是否为外部依赖（node_modules包），如果是则创建特殊的外部依赖节点，确保依赖关系图的完整性和准确性，最终形成一个能够完整反映项目内部文件依赖关系和外部包依赖的有向图结构。

[0117] 步骤S3，冗余分析。

[0118] 步骤S31，冗余文件检测。图3是根据本申请实施例的一种冗余文件检测的方法流程图，如图3所示，可以通过如下步骤进行冗余文件检测。

[0119] 从入口文件开始DFS遍历，利用深度优先搜索算法，递归地深入项目文件的依赖关系链，从入口文件出发，逐一探索其直接和间接依赖的其他文件，直至遍历完整个项目依赖网络。

[0120] 标记当前文件为已访问，在DFS遍历的过程中，每接触到一个新文件，将该文件标记为"已访问”。状态标记机制的存在，确保了每个文件节点仅被遍历一次，避免了重复访问同一文件而导致的资源浪费，也防止了死循环的发生。

[0121] 获取当前文件的依赖列表，对于每一个遍历到的文件，解析其源代码，从抽象语法树中提取出其中的导入声明和其他依赖标识符，从而形成一个具体的依赖列表，记录了该文件所有直接依赖的其他文件或模块。

[0122] 加入到依赖队列中，创建一个依赖队列，用于存储后续需要遍历分析的依赖文件路径。每当在文件中识别出新的依赖项，这些依赖项的路径会被添加进依赖队列，作为后续DFS遍历的待处理点。依赖队列的管理遵循先进先出原则，每次从队列头部取出一个路径进行处理，保证了遍历处理的连贯性和系统性。

[0123] 依赖项去重，在依赖队列处理阶段，进行依赖项的去重操作，即去除队列中重复出现的依赖文件路径，确保分析引擎不会对同一个文件进行多次处理。依赖项去重基于文件路径的唯一性，避免了不必要的重复工作，显著提高了遍历和分析项目的整体效率。

[0124] 对比所有文件节点，完成整个DFS遍历后，对比图数据结构中所有的文件节点，检查这些节点是否都出现在最终经过处理的依赖关系列表中。

[0125] 识别提取出冗余文件，如果在对比过程中发现任何一个文件节点没有出现在依赖关系列表中，即没有任何其他节点直接或间接依赖于它，那么这个文件就可以被定义为冗余文件。识别冗余文件后，将它们从项目中提取出来，进行标记。此时，开发团队可以进行人工复查，确认这些文件是否真的不再需要，决定是否安全删除或隔离，以减少项目复杂度和存储空间占用，提升项目构建和运行效率。

[0126] 步骤S32，冗余代码检测。图4是根据本申请实施例的一种冗余代码检测的方法流程图，如图4所示，可以通过如下步骤进行冗余代码检测：基于每个文件的AST树，遍历AST树，创建作用域链（全局作用域、函数作用域、块级作用域、词法作用域），创建冗余列表。收集所有作用域中的声明，包括变量，函数，类，导入。查找所有声明引用的位置，并更新引用计数。如果某个声明不存在引用位置，则存入冗余列表。

[0127] 步骤S33，第三方冗余依赖检测：收集AST中所有的导入声明，与package.json中的dependencies和devDependencies列表做对比，在package.json中声明但未在源码中出现的包，标记为冗余的第三方依赖。

[0128] 步骤S34，相似代码检测：通过语法树遍历算法，系统性地移除注释节点、空白符节点等非语义逻辑节点，并对字面量节点进行标准化处理：将字符串字面量统一替换为预定义标识，数值字面量规范化为标准数值0，布尔字面量统一为true值。该预处理过程有效消除了因具体字面量数值差异导致的语法树结构变化，为后续结构相似性分析建立统一的比较基准。

[0129] 图5是根据本申请实施例的一种相似代码检测的方法流程图，如图5所示，可以通过如下步骤进行相似代码检测：为每个代码单元（如函数、代码块）的规范化AST生成一个最小哈希指纹构建哈希指纹索引表，对具有相同或相近哈希值的代码片段进行分组聚合。通过哈希值比较操作，快速识别潜在的结构相似代码片段，形成候选相似代码集合。对筛选得到的候选代码片段，采用树编辑距离算法进行精确的结构相似性度量。该算法通过计算将一棵抽象语法树转换为另一棵树所需的最小编辑操作次数（包括节点插入、删除、替换操作），量化两个代码片段的结构差异程度。根据参与比较的语法树规模对编辑距离进行标准化，计算得出0-1区间内的相似度数值。

[0130] 进一步地，将检测结果划分为：完全重复类别（相似度≥0.9）、高度重复类别（0.7≤相似度<0.9）、中度重复类别（0.5≤相似度<0.7）、非重复类别（相似度<0.5）。针对不同重复等级，系统自动生成相应的代码重构建议：完全相似代码建议提取为公共函数模块，高度相似代码建议进行逻辑合并重构，中度相似代码建议采用设计模式进行抽象化处理。同时生成包含相似代码位置信息、相似度量化数据、重构建议方案的结构化检测报告。

[0131] 步骤S4，生成测试报告。

[0132] 步骤S41，依赖关系图生成:利用D3.js实现依赖关系图，节点至少需要包含{id，节点名称，节点类型}，边至少需要包含{源节点id，目标节点id}。

[0133] 步骤S42，冗余分析报告：输出冗余文件列表：包含路径，文件名等信息；输出冗余代码列表：包含路径，所在行；输出冗余依赖列表：包含依赖名。

[0134] 上述步骤具备如下技术效果。提升协作效率：优先级入口定位与交互式依赖图结合，可快速掌握项目架构层级与核心模块依赖关系，问题定位效率提升50%以上；提升冗余代码排查效率：排查冗余的时间从"按天计算”能缩短至"按分钟计算”，减少"冗余清理”时间；提升代码一致性：通过冗余检测，可以识别出隐形的技术债务，如相似业务代码，提示开发人员修改，提升代码一致性。

[0135] 图6是根据本申请实施例的一种项目配置文件的分析装置的结构图，如图6所示，该装置包括：

[0136] 第一确定模块61，用于从项目配置文件中确定入口文件路径，基于入口文件路径读取入口文件的源代码，并将入口文件的源代码转化为初始抽象语法树，其中，项目配置文件用于定义项目的构建配置参数。

[0137] 转换模块62，用于从初始抽象语法树中提取导入声明节点中的文件路径，将文件路径中的相对路径和别名路径分别转换为基于项目根目录的绝对路径。

[0138] 解析模块63，用于基于初始抽象语法树和绝对路径，递归解析依赖文件的源代码，并将依赖文件的源代码转化为抽象语法树。

[0139] 构建模块64，用于基于解析得到的抽象语法树，构建图数据结构，其中，图数据结构中的节点用于表示项目中的文件，边用于表示文件之间的依赖关系。

[0140] 第二确定模块65，用于若未在图数据结构中查找到文件路径与绝对路径完全匹配的目标节点，根据绝对路径是否指向外部依赖目录确定绝对路径是否为外部依赖。

[0141] 可选地，从项目配置文中确定入口文件路径，具体包括如下步骤：获取项目配置文件，按照第一优先级顺序读取项目配置文件，其中，在第一优先级顺序中，工具专用配置的优先级高于项目描述配置；按照第二优先级顺序从项目配置文件中提取入口配置字段，在第二优先级顺序中，构建入口配置的优先级高于项目主入口配置、项目主入口配置的优先级高于默认入口文件；根据入口配置字段从项目配置文中确定入口文件路径。

[0142] 可选地，将入口文件的源代码转化为初始抽象语法树，具体包括如下步骤：基于项目构建配置信息和项目依赖配置信息，识别项目配置文件中所配置的技术框架类型，并确定技术框架类型对应的语法解析器以及语法扩展插件；使用语法解析器以及语法扩展插件对入口文件的源代码进行词法分析和语法分析，生成入口文件的初始抽象语法树；基于初始抽象语法树和绝对路径，递归解析依赖文件的源代码，并将依赖文件的源代码转化为抽象语法树，包括：创建待解析文件队列，并将从初始抽象语法树中提取的依赖文件的绝对路径作为初始元素加入待解析文件队列，其中，待解析文件队列用于按顺序存储需要解析的依赖文件路径；当待解析文件队列不为空时，执行以下循环：从待解析文件队列中提取依赖文件路径；使用语法解析器以及语法扩展插件对依赖文件路径对应的文件进行解析，生成依赖文件的抽象语法树；遍历依赖文件的抽象语法树，识别并提取语法节点中的依赖路径信息，其中，语法节点包括以下至少之一：导入声明节点、导出声明节点、函数声明节点、变量声明节点和函数调用表达式节点；将提取到的依赖路径信息转换为基于项目根目录的绝对路径；将新的绝对路径添加到待解析文件队列中；持续执行上述循环，直至待解析文件队列为空。

[0143] 可选地，基于解析得到的抽象语法树，构建图数据结构，具体包括如下步骤：基于抽象语法树中的依赖关系信息，创建初始图数据结构，初始化初始图数据结构中所有节点的状态为未访问状态，并创建访问路径记录和循环依赖列表；遍历初始图数据结构中的节点，对于每个未访问节点执行深度优先遍历，在遍历过程中，将当前节点标记为访问中状态，并将当前节点加入访问路径记录；获取当前节点的依赖节点列表，遍历依赖节点列表中的每个依赖节点；判断依赖节点的状态是否为访问中状态，在依赖节点处于访问中状态的情况下，将当前访问路径记录中的节点序列添加到循环依赖列表中；在依赖节点处于未访问状态的情况下，继续递归遍历依赖节点；完成当前节点的所有依赖节点遍历后，将当前节点标记为已访问状态，并从访问路径记录中移除当前节点；持续执行遍历过程，直到所有节点均被标记为已访问状态；将循环依赖列表集成到初始图数据结构中，得到图数据结构。

[0144] 可选地，项目配置文件的分析装置还用于执行如下步骤：基于图数据结构，确定项目配置文件中的冗余文件以及冗余代码，并对冗余文件以及冗余代码进行删除。

[0145] 可选地，基于图数据结构，确定项目配置文件中的冗余文件以及冗余代码，具体包括如下步骤：收集图数据结构中所有节点的依赖关系信息，并将依赖关系信息进行去重处理，得到依赖列表；将图数据结构中的所有节点与依赖列表进行对比，将图数据结构中未出现在依赖列表中的节点确定为冗余文件；遍历抽象语法树并创建作用域链，其中，作用域链用于表示代码中的作用域层次结构；收集作用域中的声明信息，查找声明信息的引用位置，并根据引用位置更新声明信息对应的引用计数，其中，声明信息包括以下至少之一：变量声明、函数声明、类声明和导入声明；将引用计数为零的声明信息确定为冗余代码。

[0146] 可选地，根据绝对路径是否指向外部依赖目录确定绝对路径是否为外部依赖，具体包括如下步骤：将绝对路径按目录分隔符进行分割，得到路径组成部分序列；遍历路径组成部分序列，将每个路径组成部分与预定义的外部依赖目录名称进行比较；当在路径组成部分序列中找到与预定义外部依赖目录名称匹配的组成部分时，确定绝对路径的路径结构中包括外部依赖目录标识符；在绝对路径的路径结构中包括外部依赖目录标识符的情况下，确定绝对路径为外部依赖。

[0147] 可选地，根据绝对路径是否指向外部依赖目录确定绝对路径是否为外部依赖之后，还可以执行如下步骤：基于外部依赖目录标识符在绝对路径中的位置，确定外部依赖包名称部分在绝对路径中的位置；从绝对路径的位置提取外部依赖包名称作为包标识信息，并在绝对路径包括版本信息时，同时提取版本标识信息；在图数据结构中创建外部依赖节点，其中，外部依赖节点包括包标识信息，或者包括包标识信息和版本标识信息；建立从源节点到外部依赖节点的依赖边。

[0148] 可选地，项目配置文件的分析装置还用于执行如下步骤：生成抽象语法树中的节点的哈希值；基于哈希值对节点进行分组聚合，得到候选相似节点集合；对于候选相似节点集合中的节点，使用树编辑距离算法计算节点之间的相似度数值；基于相似度数值对节点进行分级分类，并根据分级分类结果生成代码重构建议；基于相似度数值和代码重构建议生成检测报告。

[0149] 可选地，根据分级分类结果生成代码重构建议，具体包括如下步骤：对于相似度数值大于等于第一阈值的节点，生成提取为公共函数模块的建议；对于相似度数值大于等于第二阈值且小于第一阈值的节点，生成进行逻辑合并重构的建议；对于相似度数值大于等于第三阈值且小于第二阈值的节点，生成采用设计模式进行抽象化处理的建议。

[0150] 可选地，生成抽象语法树中的节点的哈希值之前，还可以执行如下步骤：移除抽象语法树中的非语义逻辑节点，其中，非语义逻辑节点包括注释节点和空白符节点；将抽象语法树中的字符串字面量节点统一替换为预定义字符串标识符；将抽象语法树中的数值字面量节点规范化为统一数值表示；将抽象语法树中的布尔字面量节点统一为固定布尔值表示。

[0151] 需要说明的是，上述图6中的各个模块可以是程序模块（例如是实现某种特定功能的程序指令集合），也可以是硬件模块，对于后者，其可以表现为以下形式，但不限于此：上述各个模块的表现形式均为一个处理器，或者，上述各个模块的功能通过一个处理器实现。

[0152] 需要说明的是，图6所示实施例的优选实施方式可以参见图1所示实施例的相关描述，此处不再赘述。

[0153] 图7示出了一种用于实现项目配置文件的分析方法的计算机终端的硬件结构框图。如图7所示，计算机终端70可以包括一个或多个（图中采用702a、702b，……，702n来示出）处理器702（处理器702可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置）、用于存储数据的存储器704、以及用于通信功能的传输模块706。除此以外，还可以包括：显示器、输入 / 输出接口（I / O接口）、通用串行总线（USB）端口（可以作为BUS总线的端口中的一个端口被包括）、网络接口、电源和 / 或相机。本领域普通技术人员可以理解，图7所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，计算机终端70还可包括比图7中所示更多或者更少的组件，或者具有与图7所示不同的配置。

[0154] 应当注意到的是上述一个或多个处理器702和 / 或其他数据处理电路在本文中通常可以被称为"数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到计算机终端70中的其他元件中的任意一个内。如本申请实施例中所涉及到的，该数据处理电路作为一种处理器控制（例如与接口连接的可变电阻终端路径的选择）。

[0155] 存储器704可用于存储应用软件的软件程序以及模块，如本申请实施例中的项目配置文件的分析方法对应的程序指令 / 数据存储装置，处理器702通过运行存储在存储器704内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的项目配置文件的分析方法。存储器704可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器704可进一步包括相对于处理器702远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端70。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

[0156] 传输模块706用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端70的通信供应商提供的无线网络。在一个实例中，传输模块706包括一个网络适配器（Network Interface Controller，NIC），其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输模块706可以为射频（Radio Frequency，RF）模块，其用于通过无线方式与互联网进行通讯。

[0157] 显示器可以例如触摸屏式的液晶显示器（LCD），该液晶显示器可使得用户能够与计算机终端70的用户界面进行交互。

[0158] 此处需要说明的是，在一些可选实施例中，上述图7所示的计算机终端可以包括硬件元件（包括电路）、软件元件（包括存储在计算机可读介质上的计算机代码）、或硬件元件和软件元件两者的结合。应当指出的是，图7仅为特定具体实例的一个实例，并且旨在示出可存在于上述计算机终端中的部件的类型。

[0159] 需要说明的是，图7所示的计算机终端用于执行图1所示的项目配置文件的分析方法，因此上述命令的执行方法中的相关解释说明也适用于该电子设备，此处不再赘述。

[0160] 本申请实施例还提供了一种非易失性存储介质，非易失性存储介质包括存储的程序，其中，程序运行时控制存储介质所在的设备执行以上的项目配置文件的分析方法。

[0161] 非易失性存储介质执行以下功能的程序：从项目配置文件中确定入口文件路径，基于入口文件路径读取入口文件的源代码，并将入口文件的源代码转化为初始抽象语法树，其中，项目配置文件用于定义项目的构建配置参数；从初始抽象语法树中提取导入声明节点中的文件路径，将文件路径中的相对路径和别名路径分别转换为基于项目根目录的绝对路径；基于初始抽象语法树和绝对路径，递归解析依赖文件的源代码，并将依赖文件的源代码转化为抽象语法树；基于解析得到的抽象语法树，构建图数据结构，其中，图数据结构中的节点用于表示项目中的文件，边用于表示文件之间的依赖关系；若未在图数据结构中查找到文件路径与绝对路径完全匹配的目标节点，根据绝对路径是否指向外部依赖目录确定绝对路径是否为外部依赖。

[0162] 本申请实施例还提供了一种电子设备，包括：存储器和处理器，处理器用于运行存储在存储器中的程序，其中，程序运行时执行以上的项目配置文件的分析方法。

[0163] 处理器用于运行执行以下功能的程序：从项目配置文件中确定入口文件路径，基于入口文件路径读取入口文件的源代码，并将入口文件的源代码转化为初始抽象语法树，其中，项目配置文件用于定义项目的构建配置参数；从初始抽象语法树中提取导入声明节点中的文件路径，将文件路径中的相对路径和别名路径分别转换为基于项目根目录的绝对路径；基于初始抽象语法树和绝对路径，递归解析依赖文件的源代码，并将依赖文件的源代码转化为抽象语法树；基于解析得到的抽象语法树，构建图数据结构，其中，图数据结构中的节点用于表示项目中的文件，边用于表示文件之间的依赖关系；若未在图数据结构中查找到文件路径与绝对路径完全匹配的目标节点，根据绝对路径是否指向外部依赖目录确定绝对路径是否为外部依赖。

[0164] 上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

[0165] 在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

[0166] 在本申请的上述实施例中，采集的信息是经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、存储、使用、加工、传输、提供、公开和应用等处理，均遵守相关法律法规和标准，采取了必要保护措施，不违背公序良俗，并提供有相应的操作入口，供用户选择授权或者拒绝。

[0167] 在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

[0168] 所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

[0169] 另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

[0170] 所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对相关技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可为个人计算机、服务器或者网络设备等）执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

[0171] 以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。< / script> < / template> < / component>

Claims

1. A method of analyzing a project configuration file, characterized by, include: The entry file path is determined from the project configuration file. Based on the entry file path, the source code of the entry file is read and the source code of the entry file is transformed into an initial abstract syntax tree. The project configuration file is used to define the project's build configuration parameters. Extract the file path from the import declaration node from the initial abstract syntax tree, and convert the relative path and alias path in the file path into an absolute path based on the project root directory; Based on the initial abstract syntax tree and the absolute path, the source code of the dependent files is recursively parsed and transformed into an abstract syntax tree; Based on the abstract syntax tree obtained from the parsing, a graph data structure is constructed, wherein nodes in the graph data structure are used to represent files in the project, and edges are used to represent dependencies between the files; If no target node whose file path completely matches the absolute path is found in the graph data structure, the absolute path is determined to be an external dependency based on whether the absolute path points to an external dependency directory.

2. The method according to claim 1, characterized in that, Determine the entry file path from the project configuration file, including: Obtain the project configuration file and read the project configuration file in a first priority order, wherein, in the first priority order, the priority of tool-specific configuration is higher than that of project description configuration; The entry configuration field is extracted from the project configuration file according to the second priority order. In the second priority order, the priority of building the entry configuration is higher than that of the project main entry configuration, and the priority of the project main entry configuration is higher than that of the default entry file. The entry file path is determined from the project configuration file based on the entry configuration field.

3. The method according to claim 1, characterized in that, The source code of the entry file is transformed into an initial abstract syntax tree, including: Based on the project build configuration information and project dependency configuration information, identify the technology framework type configured in the project configuration file, and determine the syntax parser and syntax extension plugin corresponding to the technology framework type; The syntax parser and the syntax extension plugin are used to perform lexical and syntactic analysis on the source code of the entry file to generate the initial abstract syntax tree of the entry file. Based on the initial abstract syntax tree and the absolute path, the source code of the dependent files is recursively parsed, and the source code of the dependent files is transformed into an abstract syntax tree, including: Create a file queue to be parsed, and add the absolute paths of the dependency files extracted from the initial abstract syntax tree as initial elements to the file queue to be parsed, wherein the file queue to be parsed is used to store the paths of the dependency files that need to be parsed in order; When the queue of files to be parsed is not empty, the following loop is executed: Dependency file paths are extracted from the queue of files to be parsed; the files corresponding to the dependency file paths are parsed using the syntax parser and the syntax extension plugin to generate an abstract syntax tree for the dependency files; the abstract syntax tree of the dependency files is traversed, and dependency path information in syntax nodes is identified and extracted, wherein the syntax nodes include at least one of the following: import declaration nodes, export declaration nodes, function declaration nodes, variable declaration nodes, and function call expression nodes; the extracted dependency path information is converted into an absolute path based on the project root directory; the new absolute path is added to the queue of files to be parsed. Continue executing the above loop until the queue of files to be parsed is empty.

4. The method according to claim 1, characterized in that, Based on the abstract syntax tree obtained from parsing, a graph data structure is constructed, including: Based on the dependency information in the abstract syntax tree, an initial graph data structure is created, all nodes in the initial graph data structure are initialized to an unvisited state, and access path records and circular dependency lists are created. Traverse the nodes in the initial graph data structure. For each unvisited node, perform a depth-first traversal. During the traversal, mark the current node as being visited and add the current node to the access path record. Get the list of dependent nodes of the current node, and iterate through each dependent node in the list; Determine whether the dependent node is in an accessing state. If the dependent node is in an accessing state, add the node sequence in the current access path record to the circular dependency list; if the dependent node is in an unaccessed state, continue to recursively traverse the dependent node. After traversing all dependent nodes of the current node, mark the current node as visited and remove the current node from the access path record; Continue the traversal process until all nodes are marked as visited. The circular dependency list is integrated into the initial graph data structure to obtain the graph data structure.

5. The method according to claim 1, characterized in that, The method further includes: Based on the graph data structure, redundant files and redundant code in the project configuration file are identified and deleted.

6. The method according to claim 1, characterized in that, Based on the graph data structure, redundant files and redundant code in the project configuration file are identified, including: Collect the dependency information of all nodes in the graph data structure, and remove duplicates from the dependency information to obtain a dependency list; Compare all nodes in the graph data structure with the dependency list, and identify the redundant files as nodes in the graph data structure that do not appear in the dependency list. Traverse the abstract syntax tree and create a scope chain, wherein the scope chain is used to represent the scope hierarchy in the code; Collect declaration information in the scope, find the reference position of the declaration information, and update the reference count corresponding to the declaration information according to the reference position. The declaration information includes at least one of the following: variable declaration, function declaration, class declaration, and import declaration. The declaration information with a reference count of zero is identified as redundant code.

7. The method according to claim 1, characterized in that, Determining whether an absolute path is an external dependency based on whether it points to an external dependency directory includes: The absolute path is divided according to directory separators to obtain a sequence of path components; Iterate through the sequence of path components, comparing each path component with a predefined external dependency directory name; When a component matching a predefined external dependency directory name is found in the sequence of path components, it is determined that the path structure of the absolute path includes an external dependency directory identifier. If the path structure of the absolute path includes the external dependency directory identifier, the absolute path is determined to be an external dependency.

8. The method according to claim 7, characterized in that, After determining whether the absolute path is an external dependency based on whether it points to an external dependency directory, the method further includes: Based on the position of the external dependency directory identifier in the absolute path, determine the position of the external dependency package name portion in the absolute path; Extract the name of the external dependency package from the location of the absolute path as package identification information, and extract the version identification information at the same time when the absolute path includes version information; An external dependency node is created in the graph data structure, wherein the external dependency node includes the package identifier information, or includes both the package identifier information and the version identifier information; Establish dependency edges from the source node to the external dependent node.

9. The method according to claim 1, characterized in that, The method further includes: Generate the hash values ​​of the nodes in the abstract syntax tree; Based on the hash value, the nodes are grouped and aggregated to obtain a set of candidate similar nodes; For nodes in the candidate similar node set, the similarity values ​​between nodes are calculated using the tree edit distance algorithm; The nodes are classified into different levels based on the similarity scores, and code reconstruction suggestions are generated based on the classification results. A detection report is generated based on the similarity score and the code refactoring suggestions.

10. The method according to claim 9, characterized in that, Code refactoring suggestions are generated based on the hierarchical classification results, including: For nodes whose similarity values ​​are greater than or equal to the first threshold, suggestions are generated to extract them as common function modules; For nodes whose similarity values ​​are greater than or equal to the second threshold and less than the first threshold, a suggestion for logical merging and reconstruction is generated; For nodes whose similarity values ​​are greater than or equal to the third threshold and less than the second threshold, suggestions are generated that employ design patterns for abstraction.

11. The method according to claim 9, characterized in that, Before generating the hash values ​​of the nodes in the abstract syntax tree, the method further includes: Remove non-semantic logical nodes from the abstract syntax tree, wherein the non-semantic logical nodes include comment nodes and whitespace nodes; Replace all string literal nodes in the abstract syntax tree with predefined string identifiers; The numerical literal nodes in the abstract syntax tree are standardized into a unified numerical representation; The Boolean literal nodes in the abstract syntax tree are unified into fixed Boolean value representations.

12. An analysis device for project configuration files, characterized in that, include: The first determining module is used to determine the entry file path from the project configuration file, read the source code of the entry file based on the entry file path, and convert the source code of the entry file into an initial abstract syntax tree, wherein the project configuration file is used to define the project's build configuration parameters; The conversion module is used to extract file paths from the import declaration nodes from the initial abstract syntax tree, and convert the relative paths and alias paths in the file paths into absolute paths based on the project root directory, respectively. The parsing module is used to recursively parse the source code of the dependent files based on the initial abstract syntax tree and the absolute path, and transform the source code of the dependent files into an abstract syntax tree; The building module is used to construct a graph data structure based on the parsed abstract syntax tree, wherein nodes in the graph data structure represent files in the project, and edges represent dependencies between the files; The second determining module is used to determine whether the absolute path is an external dependency if no target node whose file path completely matches the absolute path is found in the graph data structure, based on whether the absolute path points to an external dependency directory.

13. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored program, wherein, when the program is executed, it controls the device where the non-volatile storage medium is located to execute the analysis method of the project configuration file as described in any one of claims 1 to 11.

14. An electronic device, characterized in that, include: A memory and a processor, the processor being configured to run a program stored in the memory, wherein the program, when running, executes the analysis method for the project configuration file as described in any one of claims 1 to 11.

15. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the method for analyzing the project configuration file as described in any one of claims 1 to 11.

Images