logicspark / berryjam Goto Github PK

🚨 The automated release from the main branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the main branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

No npm token specified.

An npm token must be created and set in the NPM_TOKEN environment variable on your CI environment.

Please make sure to create an npm token and to set it in the NPM_TOKEN environment variable on your CI environment. The token must allow to publish to the registry https://registry.npmjs.org/.

Good luck with your project ✨

Your semantic-release bot 📦🚀

Overview

Currently, console.error is used for error reporting throughout the codebase. This proposal suggests hiding console.error by default and displaying errors only when the verbose option is provided. This approach can improve code readability and provide greater control over error visibility.

Expected behavior

By default, if you run the scan method, it will not show error reporting. If you parse argument verbose in the VueScannerOption, the error report will show.

Overview

I have identified that certain import statements are not being used in any part of the file. This can cause confusion in the future.

Expected Behavior

Remove both of them

Description

Currently, the GitService class is not accessible for use in Berryjam CLI or any other applications. To make it available for external use, we need to solve this issue.

Why is this feature needed? Is there a problem that you faced?

By making this change, we enhance the reusability of the codebase, enabling external tools to benefit from the capabilities of the GitService class.

What is the solution you have in mind?

We can take one of the following approaches:

1. Export GitService Class: We can export the GitService class so that other parts of the application or external applications can import and use it.
2. Create a Public Method: Another option is to create a public method within the VueScanner class that allows external applications, such as Berryjam CLI, to access the functionality provided by GitService.

Additional Information

No response

Overview

I've noticed that this log is always displayed, which may not be necessary within the library. If users wish to view log information, they can use the verbose option instead

Expected Behavior

Remove the line and the code still work per normal.

Overview

At the moment, the recently added options of the scan method are not yet documented so users may not know they are available. Here are the 3 added options

1. verbose - to provide detailed scanning log from the console
2. ignore - to allow users to specify file paths and/or directories to be excluded from scanning
3. output - by default, the scan will output the component profiles in JSON format. Another export format is STDOUT.

Expected Behavior

• Add Scan Options right below the Usage section in a table format
• Update the description of Output subsection to default output as a JSON file and explain that a user may output in JSON, STDOUT (view results on console).

Description

In complex projects, components can become deeply nested, leading to increased complexity and potential performance issues. This issue aims to identify and count the number of nested levels within a component to help determine which components should be simplified or refactored for improved maintainability and performance.

Why is this feature needed? Is there a problem that you faced?

Let's say componentA called on componentB and also called on componentC in the same file but not at the same level as that of componentB. Here is an example:

ComponentA
-> ComponentB
    -> ComponentC

It's possible for componentA to call on both B and C at the same level but it's nor recommended them to be nested like above. It may be better for component C is be added in componentB instead.

What is the solution you have in mind?

The feature allows the front-end teams to quickly identify which components should be modified so that they are less complex., especially for components with high usages. The modification will make the UI components more maintainable and scalable.

Additional Information

Utilize the AST format to identify the deepest DOM level and collect this information to display in the ComponentProfile.

Overview

Component profile info and respective git info are separated into two JSON output. component-profile.json is not updated while the sample of git-parsed-diff.json is not yet documented.

Expected Behavior

• Replace the sample component-profile.json file with a new one that does not have git information
• Add a sample git-parsed-diff.json file under the Output subsection

Describe the bug

Based on #44, I created a function to find the end of lines in a component's file and added this information to the VueComponent interface. However, I noticed a bug in the mapComponentProfileSource method, which removes the endOfLines property at this code lines

The endOfLines property should be retained in the ComponentProfile, but it's being removed. This unintended behavior needs to be fixed.

To Reproduce

Not applicable

Expected behavior

The endOfLines property should be retained in the ComponentProfile

Node Version

Not applicable

OS

Not applicable

Browser

Not applicable

Additional Context

No response

Description

Currently, the class only collects basic git details for filename, author and datetime. However, it does not collect commit number, message or previous commit id to provide more useful information for users to take actions.

You may find GitService class here.

Why is this feature needed? Is there a problem that you faced?

1. Display more relevant data like commit number and message so that users can understand the changes made to a component
2. Improve accuracy of collection of git information and transform data into more developer-friendly format
3. Carry out data analysis for commits and team member participation to components in the project for more actionable insights

What is the solution you have in mind?

Replace all methods of GitService class with new methods using node native functions such as spawnSync from node:child_process to recursively collect git information and parse the information into a more readable format.

Additional Information

The method will not keep details of code changes.

Description

Currently, the scan is only for specific file extensions with a default exclusion set:

However, there is no way for a user to exclude additional files or directories from being scanned.

Why is this feature needed? Is there a problem that you faced?

1. Test examples or code examples are not part of a project's components so scanning them may cause results to be inaccurate
2. For large repositories, more custom exclusion allows for faster scan
3. Allow users more detailed control on what should or should not be scanned.

What is the solution you have in mind?

A method that allow developers to specify file extensions, file paths and directory paths to ignore from scanning. It may be added as Step 0 wrapped within the scan method.

Additional Information

At the moment, there is an interface for the VueScannerOption but the method is not yet developed.

Description

Count the number of lines each component has.

Why is this feature needed? Is there a problem that you faced?

Components with a high number of lines of codes should be investigated or modified. If a component is too heavy, it may need to be separated to make it easier to maintain or modify. This information is especially relevant when viewed together with the usage count.

What is the solution you have in mind?

1. uses Node.js along with the fs (File System) and path modules to read and manipulate files.
2. Define a function to count the number of lines in a given file, reading its content and splitting it by line breaks.
3. The script is executed to perform line counting on each Vue component file.

Additional Information

The function to count component usage already exists.

Describe the bug

I encountered an issue while using scanGit method, and it resulted in the following error message: "fatal: ambiguous argument '': unknown revision or path not in the working tree ..."

To Reproduce

1. Init VueScanner with the project path (It does not happen in all projects)
2. Call scan() method
3. When the code executed at scanGit method, the error is displayed

fatal: ambiguous argument '1035e8d88b9dbd3ca88813152cf7f900c9874a9c~': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

Expected behavior

When using the scanGit method, I expect the process to continue without errors. If an error occurs but doesn't impact the scanning process, it should remain invisible unless the verbose or debug option is enabled.

Node Version

18.16.1

OS

macOS

Browser

Not applicable

Additional Context

No response

Overview

At the moment, the recently added nested level count of each component is not yet documented so users may not know the information is available.

Expected Behavior

• Replace the sample JSON output with a new one with information on the nested level count of each component under the Output subsection

Overview

The purpose of this issue is to refactor the code in the file mentioned in the title to improve code quality and maintainability. At the moment, the analyzed-component-files.spec.ts has push repeated twice.

As you can see, It might not need to use push twice to push 2 objects

Expected Behavior

• Using one push with 2 objects instead.

Description

Currently, the system identifies unused components based on import statements. However, we want to enhance this feature by implementing logic that can identify unused components without relying on just import statements. This will provide a more comprehensive analysis of component usage within the project.

Why is this feature needed? Is there a problem that you faced?

The current method of identifying unused components relies only on import statements. While this approach works in many cases, it may not catch all instances of unused components. For example, components that are created but are not used in any other file. The current logic will fail to identify these unused components.

What is the solution you have in mind?

To address this issue, we aim to implement a more robust approach using Abstract Syntax Trees (AST). By parsing the project's source code and analyzing the actual usage of components within templates and scripts, we can accurately identify whether a component is used or not. This will provide a more accurate picture of component usage for developers to remove unused components and improve the overall codebase.

Additional Information

• Need to add test case(s)

Description

In the current implementation, the ComponentProfile object has a property named "total" which represents the total number of times a component is used. However, this "total" property is not directly related to its usage.

Why is this feature needed? Is there a problem that you faced?

This change will align the ComponentProfile data structure with its intended purpose, making it clearer and more intuitive for users. It will also ensure that the reported usage accurately reflects how many times a component is utilized in the codebase.
The implementation of this refactor will involve updating the relevant code within the project. The adjustment will enhance the clarity and usefulness of the ComponentProfile data, contributing to an improved developer experience when using Berryjam.

What is the solution you have in mind?

To provide a more accurate representation of a component's usage, the "total" property should be changed to "usage," which will be determined by the length of the "usageLocations" array.

Additional Information

No response

Describe the bug

I encountered a bug when I run git scan within Windows terminal. I found that the error throw fatal: cannot access [hash]@ when the gitDiffDetails has been executed. The code should execute the git rev-parse command like this instead:

git rev-parse [hash]^@

but the ^ doesn't appear on Windows terminal.

To Reproduce

1. Open the Windows terminal
2. Navigate to the directory where your project is located
3. Verify that there is a .git folder in the project you intend to scan
4. Execute your script to initiate the VueScanner.scan() method

Expected behavior

When running the scan() method with Berryjam on a Windows terminal, it should execute successfully without encountering the "fatal: cannot access [hash]@" error. The command git rev-parse [hash]^@ should function as expected on the Windows terminal, allowing the scanning process to continue without errors.

Node Version

18.16.1

OS

Windows

Browser

Not applicable

Additional Context

No response

Description

When you scan for components, you need to view on console for JSON like output. The scan should output a report in JSON format

Why is this feature needed? Is there a problem that you faced?

It is convenient for users to utilize the JSON report for their internal analytics or evaluation.

What is the solution you have in mind?

Export component profile data as a file in JSON format

Additional Information

At the moment, you can view the scanned data from console.

Describe the bug

When scanning the Quasar repository. I encountered a 'RangeError: Maximum call stack size exceeded' error. This error occurs within the getCodeConfigCompilerOptionPaths function, which seems to be causing a stack overflow due to excessive recursive calls. We need to investigate and fix this issue to ensure smooth scanning of the Quasar repository.

To Reproduce

1. Clone the Quasar project to your local computer.
2. Inside your Node.js project that uses Berryjam, initialize a VueScanner instance with the path to Quasar.
3. Execute the scan() method of the VueScanner.

Expected behavior

The getCodeConfigCompilerOptionPaths function should execute without any errors and not result in a "Maximum call stack size exceeded" error, allowing smooth scanning of the Quasar repository using the VueScanner within the Berryjam project.

Node Version

18.16.1

OS

macOS

Browser

Not applicable

Additional Context

Describe the bug

When attempting to run the project in CommonJS mode, an error occurs, stating that it cannot find the module typescript. This issue prevents the application from functioning as expected.

To Reproduce

1. Create a new Node.js project and configure it to use CommonJS module system
2. Install the "berryjam" package as a dependency for your project
3. Copy the code from the README.md of the "berryjam" package. The code contains TypeScript-specific type and interface declarations, I removed them since I mentioned using CommonJS mode
4. Execute the file to start the scanning process

Expected behavior

The application should be able to run in CommonJS mode without encountering this typescript module error.

Node Version

18.16.1

OS

No response

Browser

No response

Additional Context

Error Message:

Error: Cannot find module `typescript`
Require stack:
- ../node_modules/berryjam/lib/cjs/utils/compiler.js
- ../node_modules/berryjam/lib/cjs/vue-scanner.js
- ../node_modules/berryjam/lib/cjs/index.js
- ../main.cjs
    at Module._resolveFilename (node:internal/modules/cjs/loader:1075:15)
    at Module._load (node:internal/modules/cjs/loader:920:27)
    at Module.require (node:internal/modules/cjs/loader:1141:19)
    at require (node:internal/modules/cjs/helpers:110:18)
    at Object.<anonymous> (/Users/tong/Documents/node_modules/berryjam/lib/cjs/utils/compiler.js:35:25)
    at Module._compile (node:internal/modules/cjs/loader:1254:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
    at Module.load (node:internal/modules/cjs/loader:1117:32)
    at Module._load (node:internal/modules/cjs/loader:958:12)
    at Module.require (node:internal/modules/cjs/loader:1141:19) {

  code: 'MODULE_NOT_FOUND',

Overview

The new scanned options for the VueScanner class method not yet documented so users may not know they are available. Here are the 3 added options

1. verbose - to provide detailed scanning log from the console
2. ignore - to allow users to specify file paths and/or directories to be excluded from scanning
3. output - by default, the scan will output the component profiles in JSON format. Another export format is STDOUT.

Expected Behavior

• Add explanations for VueScannerOption Interface and OutputFormat Type before the 5-step section.

Overview

The purpose of this issue is to remove git information from ComponentProfile because issue #6 will add a separate git info which is more detailed and useful in analyzing components. Therefore, we should remove git info from ComponentProfile to ensure better maintainability.

These are 3 places we need to remove vue-scanner.ts

Initial property detail

Interface file property

Initial property component

There are 2 places to remove from analyze-component-files.spec.ts unit test

1. berryjam/tests/analyze-component-files.spec.ts

   Lines 215 to 219 in 07dc984

   	dataLastModified: "Fri Apr 28 2023",
   	lastModified: "Fri Apr 28 2023",
   	created: "2023-04-17T04:04:04.000Z",
   	createdBy: "system",
   	updatedBy: "system",

2. berryjam/tests/analyze-component-files.spec.ts

   Lines 236 to 240 in 07dc984

   	dataLastModified: "Fri Apr 28 2023",
   	lastModified: "Fri Apr 28 2023",
   	created: "2023-04-17T04:04:04.000Z",
   	createdBy: "system",
   	updatedBy: "system",

Expected Behavior

• Remove all of them
• Scan to check that there is no error in exporting components.json
• Check in components.json that git info is no longer in this JSON file

Description

In a Nuxt.js project, the pages directory is used to store all page components. While scanning the project for components, it's important to include the pages directory for comprehensive analysis. However, the issue arises when files within the pages directory are incorrectly marked as components.

Why is this feature needed? Is there a problem that you faced?

As it stands, the component scanner may mistakenly identify files within the pages directory as components. The component scanner should include the pages directory during the scanning process but should not mark the files within it as components. This ensures that page components are properly distinguished from other components in the project.

What is the solution you have in mind?

Adjust the component scanning process to exclude the pages directory from being marked as components, while still scanning it for other purposes. This way, the distinction between page components and other components in the project is maintained.

Additional Information

• Nuxt.js version: 3.x.x

This issue is essential for ensuring the accurate identification of components in Nuxt.js projects. Your attention to this matter is greatly appreciated.

Describe the bug

During a recent scan of the koel repository, I discovered that the InviteUserForm component does not have a children property in the components.json. This missing property is important for representing the component hierarchy and relationships accurately. We should add the children property to ComponentProfile for components like InviteUserForm and any others that may be affected.

To Reproduce

1. Scan the 'koel' repository using 'berryjam.'
2. Inspect the components.json file for the InviteUserForm component.

Expected behavior

The InviteUserForm component and every component should include a children property in its ComponentProfile. This issue should be addressed to ensure that the components.json file represents the component hierarchy.

Node Version

18.16.1

OS

macOS

Browser

Not applicable

Additional Context

No response

Overview

Although there is an explanation for Nuxt project in the documentation, it is not documented in the Get Started section of README.md so that users can get started quickly.

Expected Behavior

• Add a short note that .nuxt folder is needed for scanning.

Describe the bug

The error will occur when the file .tsx is scanned.

To Reproduce

1. Clone ant-design-vue from https://github.com/vueComponent/ant-design-vue
2. In Node project, create VueScanner instance within the ant-design-vue path that you have cloned to
3. Use scan() method
4. The error will occur

Expected behavior

It should not show the error like that.

Node Version

18.16.1

OS

macOS

Browser

Not applicable

Additional Context

Error: Cannot find module '@babel/preset-typescript'
Require stack:
- .../node_modules/@babel/core/lib/config/files/plugins.js
- .../node_modules/@babel/core/lib/config/files/index.js
- .../node_modules/@babel/core/lib/index.js
- .../node_modules/berryjam/lib/cjs/utils/compiler.js
- .../node_modules/berryjam/lib/cjs/vue-scanner.js
- .../node_modules/berryjam/lib/cjs/index.js

Make sure that all the Babel plugins and presets you are using
are defined as dependencies or devDependencies in your package.json
file. It's possible that the missing plugin is loaded by a preset
you are using that forgot to add the plugin to its dependencies: you
can workaround this problem by explicitly adding the missing package
to your top-level package.json.