Script Abstraction
psimk opened this issue · 0 comments
This issue discusses the next milestone for Pota and also outlines individual issues that need to be completed to reach that milestone.
Next Milestone
Pota released with template and scripts packages, templates are your base project boilerplates and scripts are collections of JS scripts that interact with your project in some meaningful way, e.g. bundling.
Currently there only exist scripts packages for bundling, we should move forward and continue abstracting more project utilities inside of scripts packages. As we have already experience with abstracting bundlers, placing linters, code generation tools, test runners and formatters into their own scripts packages would help reduce redundancy between templates, make testing these scripts packages easier - and for the end user - simplify their usage and make for easy upgrades.
New Scripts Packages
More Agency for Templates
Abstracting scripts away from their templates creates a problem - "how do we later include them in new projects?".
When creating a new project, currently, create-pota adds @pota/cli and a selected scripts package. create-pota itself is also responsible for "knowing" what scripts package a template supports, this is awkward as if we upgrade a template to support a new scripts package, then create-pota needs an update as well.
We should allow templates to define a pota field in their package.json, similar to how scripts use it to describe their commands. This field would describe what scripts packages can work with the template, which are recommended, their grouping (bundler, formatter or linter)and if needed the combination.
That field could then be picked up by create-pota and guide the creation tool into what prompts it should show. This also means that templates that do not have a pota field defined, will have no additional prompts related to scripts.