You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 10, 2022. It is now read-only.
Historically wp-dev-lib has relied on bash scripts and global environment dependencies such as a *nix operating system, PHP CLI, subversion, git, mysql server and client -- all running on the host machine that is also running the dev-lib tasks. It also makes assumptions about Vagrant based virtual environments (based on the current process user) or when Docker config files are present in the project root directory.
All of this make it hard to run the dev-lib reliably in most environments, especially locally.
This project also aims to require very little configuration and setup from the user so it has to make assumptions and provide "good defaults".
Solutions
There could be two possible solutions to this:
Rewrite the codebase to use proper dependency management to ensure the correct versions of software are used for each task. This would take a significant amount of time and potentially break existing setups.
Introduce a Docker image that includes all the necessary dependencies to run the dev-lib tasks. This doesn't solve the core issue but is much quicker to implement.
Docker images still can't bundle every version of PHP, Node and MySQL so we would need to start by providing a base image that can run the default configuration. Bundling different services in a single container is considered a bad design but we're solving for non-production environments and the ease of use.
We could also include a few Dockerfile examples that would support custom setups with older versions of PHP, for example.
Examples
Projects with wp-dev-lib added as a Composer dependency could introduce a docker-compose.yml file to define the environment like so:
version: '3.6'services:
wpdevlib:
image: xwpco/wp-dev-lib:VERSIONworking_dir: /var/www/htmlvolumes:
- .:/var/www/htmlenvironment:
CHECK_SCOPE: all
and all existing tasks could be run inside that environment:
docker-compose run wpdevlib composer lint
or the tasks defined in composer.json or package.json could be updated to run inside the virtual environment:
Historically wp-dev-lib has relied on bash scripts and global environment dependencies such as a *nix operating system, PHP CLI, subversion, git, mysql server and client -- all running on the host machine that is also running the dev-lib tasks. It also makes assumptions about Vagrant based virtual environments (based on the current process user) or when Docker config files are present in the project root directory.
All of this make it hard to run the dev-lib reliably in most environments, especially locally.
This project also aims to require very little configuration and setup from the user so it has to make assumptions and provide "good defaults".
Solutions
There could be two possible solutions to this:
Rewrite the codebase to use proper dependency management to ensure the correct versions of software are used for each task. This would take a significant amount of time and potentially break existing setups.
Introduce a Docker image that includes all the necessary dependencies to run the dev-lib tasks. This doesn't solve the core issue but is much quicker to implement.
Docker images still can't bundle every version of PHP, Node and MySQL so we would need to start by providing a base image that can run the default configuration. Bundling different services in a single container is considered a bad design but we're solving for non-production environments and the ease of use.
We could also include a few
Dockerfile
examples that would support custom setups with older versions of PHP, for example.Examples
Projects with wp-dev-lib added as a Composer dependency could introduce a
docker-compose.yml
file to define the environment like so:and all existing tasks could be run inside that environment:
or the tasks defined in
composer.json
orpackage.json
could be updated to run inside the virtual environment:The text was updated successfully, but these errors were encountered: