🚨 The automated release from the dev 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 dev 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.

Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two Factor Authentication for your account, set its level to "Authorization only" in your account settings. semantic-release cannot publish with the default "
Authorization and writes" level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.

Good luck with your project ✨

Your semantic-release bot 📦🚀

Cli is not working with Windows. We made it thinking about a unix environment.

Description:

To improve the usability and adoption of Vulcan, it is crucial to provide comprehensive documentation that covers the tool's overall structure and guides contributors in adding new presets. Proper documentation will ensure that users have clear instructions on how to set up, configure, and extend Vulcan to suit their needs.

The objective of this issue is to create detailed documentation for Vulcan, covering its architecture, usage guidelines, and providing a dedicated guide for contributors who want to add new presets to the tool. This documentation will facilitate the understanding and usage of Vulcan, encouraging contributions and making it easier for users to customize Vulcan to their specific requirements.

Tasks:

• Define the structure and sections for the Vulcan documentation, including architecture, installation, configuration, and usage guidelines.
• Create an overview of the Vulcan tool, explaining its purpose, features, and benefits.
• Provide clear instructions on how to install Vulcan and set up the necessary dependencies.
• Document the configuration options available for Vulcan, explaining their purpose and usage.
• Outline the process for adding new presets to Vulcan, including the necessary steps, guidelines, and best practices.
• Include examples and code snippets to illustrate the usage and customization of Vulcan and its presets.
• Test the documentation by following the instructions and ensuring accuracy and clarity.
• Perform a review of the documentation to ensure consistency, completeness, and adherence to the project's style guide.
• Update the project's README and contribute guidelines to reference the newly created documentation.
• Publish the documentation on a suitable platform or integrate it into the project's existing documentation system.

Description:

Currently, the version ID is generated exclusively in the webpack config, limiting its availability and usage in other parts of the project. To improve flexibility and enable passing the version ID to the prebuild context and other relevant processes, we need to generate the version ID directly in the dispatcher.

The goal of this issue is to modify the project's dispatcher to generate the version ID and make it accessible throughout the prebuild and related processes. This will provide a consistent versioning mechanism and allow for better integration with other parts of the project.

Tasks:

• Modify the dispatcher to generate the version ID during the build process.
• Update the necessary build scripts and commands to utilize the version ID generated in the dispatcher.
• Ensure the generated version ID is accessible in the prebuild context and other relevant processes.
• Test the build process with the updated dispatcher to verify the correct generation and usage of the version ID.
• Document the changes in the project's README and provide clear instructions on how to access and utilize the generated version ID.
• Perform code review and ensure the implementation meets quality standards.
• Update the project's documentation and contribute guidelines to reflect the changes and provide information on contributing to the project.

Acceptance Criteria:

• The version ID should be generated within the dispatcher during the build process.
• Build scripts and commands should be updated to use the version ID generated in the dispatcher.
• The generated version ID should be accessible in the prebuild context and other relevant processes.
• The build process with the updated dispatcher should be tested to ensure the correct generation and usage of the version ID.
• The README should be updated with clear instructions on how to access and utilize the generated version ID.
• All tasks should be completed and tested.
• The code should undergo a thorough review and adhere to the project's quality standards.

Description:

Currently, our project requires the package manager to be manually set before running related commands. This can be inconvenient for developers who use different package managers, such as npm or yarn.

The goal of this issue is to implement a feature that automatically detects the package manager used in the development environment. This will provide a smoother experience and make the project setup and execution process easier for developers.

Tasks:

• Implement logic to automatically detect the package manager.
• Update relevant scripts and commands to utilize the detected package manager.
• Test the detection in different environments and scenarios.
• Document the new feature in the README, providing clear instructions on how to run the project.
• Perform code review and ensure the implementation meets quality standards.
• Update documentation to reflect the changes and provide information on how to contribute to the project.

Acceptance Criteria:

• The package manager should be detected correctly in different environments.
• Relevant scripts and commands should be updated to use the detected package manager.
• Automatic detection should work without the need for additional configurations.
• The README should be updated with the necessary information to run the project using the detected package manager.
• All tasks should be completed and tested.
• The code should be reviewed and meet project quality standard

Description:

Currently, when the Azion/Vulcan Edge function (worker) cannot find an asset and there is no handled 404 response for server-side generated (SSG) pages, a generic 404 error is displayed. To enhance the user experience and branding, we want to create a custom 404 page that aligns with the platform's design and provides relevant information to the users.

The goal of this issue is to implement a custom 404 page within the Azion/Vulcan platform. This page will be displayed when a requested asset or SSG page is not found, improving the user experience and providing a more informative and visually appealing error message.

Tasks:

• Design and create a custom 404 page template that aligns with the platform's design guidelines.
• Implement the necessary logic in the Azion/Vulcan Edge function to detect and display the custom 404 page when an asset or SSG page is not found.
• Update the server-side generated (SSG) rendering to return the custom 404 page when a requested page is not found.
• Test the custom 404 page in various scenarios to ensure its functionality and visual appeal.
• Document the usage and configuration of the custom 404 page in the platform's documentation.
• Perform code review and ensure the implementation meets quality standards.
• Update the project's documentation and contribute guidelines to reflect the changes and provide information on contributing to the project.

Acceptance Criteria:

• A custom 404 page should be designed and implemented to align with the platform's design guidelines.
• The Azion/Vulcan Edge function should be updated to detect and display the custom 404 page when an asset or SSG page is not found.
• Server-side generated (SSG) rendering should return the custom 404 page when a requested page is not found.
• The custom 404 page should be tested in different scenarios to ensure its functionality and visual appeal.
• The usage and configuration of the custom 404 page should be documented in the platform's documentation.
• All tasks should be completed and tested.
• The code should undergo a thorough review and adhere to the project's quality standards.

Description:

As a Vulcan user I would like to have a custom 404 error page to import into my worker. Currently, when a requested resource is not found, an "Object not found" appears on the screen.

Example:

import { mountSSG, 404NotFound } from "#edge";
  try {
    const myApp = mountSSG(event.request.url, AZION.VERSION_ID);
    const response = await fetch(myApp)
    return response;
  } catch (e) {
    return  404NotFound;
  }

Description:
To improve maintainability and localization of strings used for output messages in the project, it is beneficial to introduce a dedicated message layer. This message layer will serve as a centralized storage for all the strings used in the project's output messages, making it easier to manage, update, and support multiple languages or localization.

The goal of this issue is to establish a message layer that stores all the strings used for output messages in a centralized manner. This will provide a more organized and maintainable approach to managing strings, making it simpler to update and translate them as needed.

Through Hugo preset and this project, when I open Neovim on the root path of the project for some reason a watcher waiting for changes on the code (I supose) retriggers de dev command, when it's really not needed, event though I'm not making any changes on the source myself.

1. I know for a fact Neovim changes files when opened, here is what it change without the dev command up:

$ fswatch .
/Users/tiago.krebs/Projetos/tiagokrebs.com/.git/modules/themes/hugo-coder/index.lock
/Users/tiago.krebs/Projetos/tiagokrebs.com/.git/index.lock
/Users/tiago.krebs/Projetos/tiagokrebs.com/.git/index
/Users/tiago.krebs/Projetos/tiagokrebs.com/.git/index
/Users/tiago.krebs/Projetos/tiagokrebs.com/.git/modules/themes/hugo-coder/index.lock

2. It's obvious that the dev command changes a lot of things when I run it, but it seems to change two times:

$ fswatch .
[...]
/Users/tiago.krebs/Projetos/tiagokrebs.com/vulcan-20240518082209.temp.js
/Users/tiago.krebs/Projetos/tiagokrebs.com/public
[...]
/Users/tiago.krebs/Projetos/tiagokrebs.com/vulcan-20240518082209.temp.js <--- again
/Users/tiago.krebs/Projetos/tiagokrebs.com/public/404.html <--- again
[...]

3. When I have the dev command up and open Neovim things go crazy. Neovim triggers those changes inside .git, then the watcher changes a lot of things on the folder, Neovim seems like to catch that and changes things inside the .git again, which triggers the dev command one more time. This keeps repeating to infinity.

Maybe the watcher should ignore the .git folder?

Description:

To enhance the visual consistency and readability of console messages, it is important to create a utility function that generates standardized message formats. This utility function will ensure that console messages adhere to a consistent design across the project, making it easier for developers to read and understand the displayed information.

The goal of this issue is to develop a utility function that can be used to generate consistent console messages with a standardized design. This utility will provide a convenient way to format and display important information, error messages, warnings, or any other relevant output in a visually consistent manner.

Tasks:

• Design and implement a utility function to generate standardized console messages.
• Define the structure and format of console messages for different types of outputs (information, error, warning, etc.).
• Incorporate the utility function into relevant parts of the project's codebase to ensure consistent message design.
• Test the utility function in various scenarios to verify its functionality and consistency.
• Document the usage and formatting guidelines for the console message utility.
• Perform code review and ensure the implementation meets quality standards.
• Update the project's documentation and contribute guidelines to reflect the changes and provide information on contributing to the project.

We need to enable the application cache and image optimization rules during the deployment process in Vulcan. Currently, these rules are not being applied, and we would like to optimize the caching of our application and improve image delivery performance.

Description:

Currently, the project lacks a robust error handling mechanism for unhandled errors that cause the program to crash unexpectedly. It is crucial to implement a solution to catch and handle these unhandled errors gracefully, providing useful error messages and preventing abrupt program termination.

The objective of this issue is to improve the project's stability and user experience by implementing a comprehensive error handling mechanism for unhandled errors. This will ensure that errors are properly caught and reported, allowing for graceful recovery or termination, and reducing the impact on the end-users.

Description

We need to implement a feature that allows updating (PATCH) Azion Edge Functions without creating new functions during each deployment. This feature will provide a seamless process for updating the code logic of existing functions, enabling us to introduce improvements, bug fixes, or new features without disrupting the existing infrastructure or requiring manual intervention.

Description

We need to implement a watch propagation mechanism that monitors and verifies the propagation of application changes across the edge networks. This will allow us to ensure that any modifications or updates to our application are correctly distributed and accessible across all edge locations.

Description:

Currently, the handler requires the explicit insertion of a version_id to specify the desired version of the API. This can be burdensome for developers and may lead to errors if the version_id is not provided correctly. To improve the developer experience and ensure seamless integration with the API, we need to eliminate the mandatory requirement of version_id in the handler. Instead, the handler should automatically fetch the latest version of the API.

The goal of this issue is to modify the handler logic to eliminate the need for explicit insertion of version_id and establish a collaboration with the API team to ensure that the handler always fetches the latest version of the API.

Current API example:

import { mountSPA } from "#edge";

  try {
    const myApp = mountSPA(event.request.url, AZION.VERSION_ID);
    const response = await fetch(myApp)
    return response;
  } catch (e) {
    return new Response(e.message || e.toString(), { status: 500 });
  }

Wanted

import { mountSPA } from "#edge";

  try {
    const myApp = mountSPA(event.request.url;
    const response = await fetch(myApp)
    return response;
  } catch (e) {
    return new Response(e.message || e.toString(), { status: 500 });
  }

Description:

Currently, our bundling process relies on webpack as the default bundler. However, we want to enhance the flexibility and performance of our project by introducing support for esbuild as an alternative bundler.

The goal of this issue is to implement the necessary changes to enable the usage of esbuild as a bundler in our project. This will provide developers with an option to leverage the benefits of esbuild, such as faster bundling times and optimized output.

Tasks:

• Integrate esbuild as a bundler option in our project.
• Implement the required configuration changes to enable esbuild as the default bundler.
• Update relevant build scripts and commands to utilize esbuild for bundling.
• Test the bundling process with esbuild in different scenarios and environments.
• Document the usage of esbuild in the project's documentation, including instructions on how to switch between bundlers.
• Perform code review and ensure the implementation meets quality standards.
• Update the project's README and contribute guidelines to reflect the changes and provide information on contributing to the project.

Acceptance Criteria:

• esbuild should be integrated as an alternative bundler in our project.
• The necessary configuration changes should be made to enable esbuild as the default bundler.
• Build scripts and commands should be updated to utilize esbuild for bundling.
• The bundling process with esbuild should be tested in various scenarios and environments.
• Documentation should be updated to include instructions on using esbuild and switching between bundlers.
• All tasks should be completed and tested.
• The code should undergo a thorough review and adhere to our project's quality standards.

Description

To streamline our development and deployment processes, we need to implement Continuous Integration and Continuous Deployment (CI/CD) pipelines. CI/CD will automate the build, testing, and deployment of our applications, ensuring efficient and reliable software delivery.

Description:

To improve error handling and consistency across the project, it is essential to establish error standards and define appropriate status codes within the #errors layer. By doing so, we can ensure that errors are handled consistently throughout the application and provide meaningful status codes that align with industry best practices.

The objective of this issue is to define error standards and assign specific status codes for different error scenarios within the #errors layer. This will help streamline error handling, enhance the developer experience, and provide clear and standardized error responses to users.

Description:
Currently, the project only supports server-side rendering (SSR) for static content. To enhance the project's capabilities and provide a more versatile rendering option, it is necessary to add support for SSR with popular frameworks.

The objective of this issue is to extend the project's rendering capabilities by implementing server-side rendering support for various frameworks. This will allow developers to leverage the benefits of SSR for dynamic content and improve performance and interactivity in their applications.

Description:

To make the Vulcan package easily accessible to the public and foster community involvement, it is crucial to publish the package on the npm registry and open the repository for contributions. Publishing on npm allows users to easily install and utilize Vulcan in their projects, while opening the repository encourages collaboration and improvements from the community.

The goal of this issue is to publish the Vulcan package on the npm registry and open the repository for contributions. This will make the package readily available for users to install and provide a platform for the community to contribute, report issues, and suggest enhancements.

Description:

To ensure the reliability and functionality of the Vulcan tool, it is crucial to implement automated testing specifically tailored for Vulcan. Automated tests will allow us to verify the different functionalities and features of Vulcan, ensuring that it operates as intended and delivers a robust user experience.

The objective of this issue is to introduce automated testing for Vulcan to validate its functionality, test different commands and options, and detect any regressions or issues. This will help ensure the stability and reliability of Vulcan, enabling smoother development and improving the overall quality of our tool.

Description:

To facilitate local development and testing of the build process before deployment to the Edge environment, it is essential to create a mock environment that closely replicates the Edge environment's behavior. This will enable developers to validate the build locally and catch any issues or misconfigurations before deploying to the actual Edge environment.

The objective of this issue is to develop a mock environment that simulates the Edge environment's behavior, allowing local testing of the build process. This will provide a safe and controlled environment for developers to validate their changes, reducing the risk of deployment issues and improving the overall development workflow.