Refactor/config build process#102
Conversation
Introduces development container setup with Docker, VS Code, and Codespaces support, adds ESLint and Stylelint configuration, and Playwright E2E test config. Removes legacy CI and build files (.travis.yml, .scrutinizer.yml, .codeclimate.yml, .codecov.yml, gulpfile.js, package.json.bak). Updates .gitattributes for improved export and line ending handling. Adds coding standards and review instructions, collection schema, and various GitHub workflow assets. Renames .phpcs.xml to .github/linting/phpcs.xml and adds phpcs.xml.dist for coding standards.
…adability and maintainability
…p formatting; add .prettierignore for better code style management
|
Warning Rate limit exceeded@krugazul has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 13 minutes and 12 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (55)
Note
|
Summary of ChangesHello @krugazul, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly refactors the project's development and build infrastructure. The changes aim to modernize the development workflow, improve code quality, and ensure better project hygiene by introducing a robust Docker-based development environment, implementing new linting and code review tools, and removing legacy configurations. This will lead to a more streamlined and consistent development process for the TO Specials plugin. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request is a significant and valuable refactoring of the project's build process and development environment. The introduction of a devcontainer, standardized linting, formatting, and testing scripts via package.json and composer.json will greatly improve developer experience and code quality. The cleanup of old configuration files is also a welcome change.
My review focuses on a few areas to further refine the new setup:
- Streamlining the Docker build process to remove redundancy.
- Improving security by avoiding hardcoded credentials in the
docker-composeconfiguration. - Correcting some minor issues in the newly added documentation and prompt files.
Overall, this is an excellent update that modernizes the project's tooling.
| # Copy package files and install dependencies | ||
| COPY package*.json ./ | ||
| RUN npm install | ||
|
|
||
| # Copy composer files and install dependencies | ||
| COPY composer.json composer.lock* ./ | ||
| RUN composer install --no-dev --optimize-autoloader |
There was a problem hiding this comment.
These steps to copy package manager files and install dependencies should be removed from the Dockerfile. They are redundant because devcontainer.json's postCreateCommand already handles npm install and composer install. More importantly, these Dockerfile commands run during the image build, potentially on outdated lock files, and before the actual project workspace is mounted. The composer install --no-dev command is also incorrect for a development container, as development dependencies are essential for tasks like testing and linting. The installation should happen in the postCreateCommand to ensure it uses the latest files from your workspace and includes dev dependencies.
| } | ||
| }, | ||
| "forwardPorts": [3000, 8000, 8080, 9000], | ||
| "postCreateCommand": "sudo apt-get update && sudo apt-get install -y wget unzip && composer install && npm install", |
There was a problem hiding this comment.
The postCreateCommand is a bit redundant. The apt-get update and apt-get install -y wget unzip commands are already executed in the Dockerfile. To streamline the setup and avoid unnecessary steps, this command should be simplified to only install project dependencies.
| "postCreateCommand": "sudo apt-get update && sudo apt-get install -y wget unzip && composer install && npm install", | |
| "postCreateCommand": "composer install && npm install", |
| environment: | ||
| WORDPRESS_DB_HOST: db | ||
| WORDPRESS_DB_USER: wordpress | ||
| WORDPRESS_DB_PASSWORD: wordpress | ||
| WORDPRESS_DB_NAME: wordpress |
There was a problem hiding this comment.
Hardcoding credentials, even for a local development environment, is not a good practice. It can lead to accidental commits of sensitive information if this pattern is copied elsewhere. It's better to use environment variables sourced from a .env file, with sensible defaults for convenience. This allows each developer to have their own local credentials without committing them to the repository. Remember to add .env to your .gitignore file.
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: ${WORDPRESS_DB_USER:-wordpress}
WORDPRESS_DB_PASSWORD: ${WORDPRESS_DB_PASSWORD:-wordpress}
WORDPRESS_DB_NAME: ${WORDPRESS_DB_NAME:-wordpress}| environment: | ||
| MYSQL_DATABASE: wordpress | ||
| MYSQL_USER: wordpress | ||
| MYSQL_PASSWORD: wordpress | ||
| MYSQL_ROOT_PASSWORD: rootpassword |
There was a problem hiding this comment.
Hardcoding credentials, even for a local development environment, is not a good practice. It can lead to accidental commits of sensitive information if this pattern is copied elsewhere. It's better to use environment variables sourced from a .env file, with sensible defaults for convenience. This allows each developer to have their own local credentials without committing them to the repository. Remember to add .env to your .gitignore file.
environment:
MYSQL_DATABASE: ${MYSQL_DATABASE:-wordpress}
MYSQL_USER: ${MYSQL_USER:-wordpress}
MYSQL_PASSWORD: ${MYSQL_PASSWORD:-wordpress}
MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD:-rootpassword}| environment: | ||
| PMA_HOST: db | ||
| PMA_USER: wordpress | ||
| PMA_PASSWORD: wordpress |
There was a problem hiding this comment.
Hardcoding credentials, even for a local development environment, is not a good practice. It can lead to accidental commits of sensitive information if this pattern is copied elsewhere. It's better to use environment variables sourced from a .env file, with sensible defaults for convenience. This allows each developer to have their own local credentials without committing them to the repository. Remember to add .env to your .gitignore file.
environment:
PMA_HOST: db
PMA_USER: ${PMA_USER:-wordpress}
PMA_PASSWORD: ${PMA_PASSWORD:-wordpress}| title: "Playwr - documentation | ||
| - instructions | ||
| - guides | ||
| version: "1.0.0" | ||
| permalink: "/instructions/playwright-tests" | ||
| license: "GPL-3.0" | ||
| type: "instructions" | ||
| mode: "agent" | ||
| author: "LightSpeedWP Team" | ||
| contributors: | ||
| - name: "Ash Shaw" | ||
| github: "ashleyshaw" | ||
| - name: "LightSpeedWP" | ||
| github: "lightspeedwp" | ||
| tags: | ||
| - playwright | ||
| - testing | ||
| - automation | ||
| - browser | ||
| - MCP | ||
| - CI/CD | ||
| - best-practices | ||
| categories: | ||
| - documentation | ||
| - instructions | ||
| - guides | ||
| version: "1.0.0" | ||
| permalink: "/instructions/playwright-tests" | ||
|
|
||
| type: "instructions" | ||
| mode: "agent" | ||
| --- |
There was a problem hiding this comment.
The YAML frontmatter in this file appears to be malformed due to duplicated keys (title, categories, version, permalink, type, mode). This was likely a copy-paste error and will cause issues with any tools that parse this frontmatter. Please consolidate the keys to create a valid YAML block.
---
title: "Playwright Test Instructions"
description: "Guidelines for writing, organizing, and maintaining Playwright tests for LightSpeed projects, with a focus on WordPress themes, blocks, and custom patterns."
author: "LightSpeedWP Team"
contributors:
- name: "Ash Shaw"
github: "ashleyshaw"
- name: "LightSpeedWP"
github: "lightspeedwp"
tags:
- playwright
- testing
- automation
- browser
- MCP
- CI/CD
- best-practices
categories:
- documentation
- instructions
- guides
version: "1.0.0"
permalink: "/instructions/playwright-tests"
license: "GPL-3.0"
type: "instructions"
mode: "agent"
---| Refactor the `typography` section in `theme.json`: | ||
| - Add named font sizes using slugs (e.g. small, medium, large) | ||
| - Include fluid scaling settings where appropriate | ||
| - Ensure all typography tokens match the project’s design system | ||
| - Provide the updated JSON snippet | ||
|
|
||
| Refactor the `typography` section in `theme.json`: | ||
| - Add named font sizes using slugs (e.g. small, medium, large) | ||
| - Include fluid scaling settings where appropriate | ||
| - Ensure all typography tokens match the LSX Design System | ||
| - Provide the updated JSON snippet |
There was a problem hiding this comment.
This prompt has duplicated sections. The second section seems to be a more specific version of the first (referencing 'LSX Design System'). Please remove the duplicated and less specific section to improve clarity.
| Refactor the `typography` section in `theme.json`: | |
| - Add named font sizes using slugs (e.g. small, medium, large) | |
| - Include fluid scaling settings where appropriate | |
| - Ensure all typography tokens match the project’s design system | |
| - Provide the updated JSON snippet | |
| Refactor the `typography` section in `theme.json`: | |
| - Add named font sizes using slugs (e.g. small, medium, large) | |
| - Include fluid scaling settings where appropriate | |
| - Ensure all typography tokens match the LSX Design System | |
| - Provide the updated JSON snippet | |
| Refactor the `typography` section in `theme.json`: | |
| - Add named font sizes using slugs (e.g. small, medium, large) | |
| - Include fluid scaling settings where appropriate | |
| - Ensure all typography tokens match the LSX Design System | |
| - Provide the updated JSON snippet |
| "require": { | ||
| "php": ">=7.2", | ||
| "composer/installers": "^2.0.0" | ||
| "php": ">=8.0", |
There was a problem hiding this comment.
Updating the required PHP version to >=8.0 is a good move. To ensure all developers and the CI environment use a consistent PHP version for dependency resolution, it's a best practice to specify the target PHP version in your composer.json config.platform. This prevents composer from installing packages incompatible with your target production environment.
"php": ">=8.0"2 participants
This pull request introduces a comprehensive development environment setup and streamlines configuration for the TO Specials plugin project. It adds devcontainer support with Docker-based WordPress and MySQL services, enforces code quality and formatting standards, and removes legacy static analysis and code coverage configs. The changes also improve project documentation, build, and distribution hygiene.
Development environment setup:
.devcontainerconfiguration, includingDockerfile,devcontainer.json, anddocker-compose.yml, to enable local development with WordPress, MySQL, phpMyAdmin, Node.js, Composer, Playwright, and VSCode extensions. This supports rapid plugin development and testing in a consistent environment. [1] [2] [3]Code quality and tooling:
.eslintrc.jsonwith WordPress JavaScript standards and project-specific rules, and added.browserslistrcto define browser support targets for frontend assets. [1] [2].coderabbit.yamlto provide detailed review, linting, and documentation instructions tailored to WordPress and the TO Specials plugin, improving code review automation and consistency.Project hygiene and distribution:
.distignoreand.gitattributesto better control which files are included in plugin distributions and archives, ensuring only necessary files are shipped and that line endings are consistent across platforms. [1] [2]Cleanup of legacy configs:
.codeclimate.ymland.codecov.yml, indicating a shift away from legacy static analysis and coverage tools in favor of new linting and review workflows. [1] [2]