Should zip task should ignore `/vendor` directory commonly used for Composer packages?
daviedR opened this issue · comments
Hi there,
Thanks for creating this library!
I was exploring this library and found out that the default Zip task doesn't exclude /vendor directory which is commonly used for Composer packages. There are a lot of WordPress projects are using Composer packages, like WPCS, etc. So I think /vendor should be excluded on the Zip task.
Please excuse me while I reveal some ignorance here—while I've definitely used Composer in the past, it's not a regular part of my workflow.
The purpose of the zip task is to export a production-ready package that can be installed as a WordPress plugin or theme. If your plugin's production code relies on Composer packages, but they are excluded from the zip archive, would the plugin function when installed from the zip?
I understand that you wouldn't want WPCS in the production archive, since it's a development tool. Does Composer differentiate between dependencies and dev dependencies like NPM does?
Regardless of how Composer is being used in a project, I wouldn't want to exclude any folder from a production zip unless it was specified as a src folder for a custom task. Even then, the config for the zip task has to be modified to tell it to check the task for a src folder to ignore (via the ignoreSrc array). Of course there are exceptions based on how the project is expected to be structured at a very basic level, ignoring package.json and lock files, node_modules (since JS should be compiled in the distributed files), and gulp files.
Let me know if I'm way off base.
Hi @cr0ybot
Composer does differentiate dev dependencies (require-dev) and dependencies (require).
I understand your point of view. There's chance that a project requires some packages from Composer for its production version.
In my case, I only use Composer packages (e.g. WPCS, WP Theme Review) for development. So, I will modify the Zip task's config then.
If there is a way for the zip task to ignore dev dependencies while including standard dependencies, then I think that's definitely something that could/should be built-in. Let's keep this issue open for now. PRs welcome!
After some further research, it doesn't look easy, potentially not even practical, to try to detect dev dependencies and ignore only those.
I think one way to handle this would be to bring the composer install step into the workflow, which could then run the proper install command depending on the intent:
- During 'dev' (default):
composer install - During 'zip': 'composer install --no-dev'.
This would require a configurable composer task, I think.