Add optional input and output directory arguments to scripts/generate-icons.js
#1064
Conversation
Enable generate-icons.js to be used from other projects where the input and output directory paths may be different. I didn't add a CLI parser dependency because the arguments are so simple, but we should add one if they become more complex.
This speeds up incremental runs of `yarn format` and `yarn lint` significantly.
|
Should we perhaps add all icons used by our apps in frontend-shared instead, and then use the already generated icons there? That would mean we don't need to modify the script, but I might be missing something. |
If icons are generally useful, it makes sense to include them in this package. However I do think it would be useful to have a way to build and iterate on project-specific app icons without having to always add them to the shared package. For example if we have SVG icons for the different content sources in the LMS app, I think it makes sense to keep them in that project alongside the code that uses them. |
|
Good point. It will also allow for faster prototyping with the option to move the icons here later, if it makes sense. |
|
Just wanted to add a comment: I agree that typically we want to include icon components in this package, so that they can be seen as a collection in the pattern library and are generally organized in one place, but I think it's reasonable to generate icon components in other projects from time to time, especially if you're prototyping or otherwise unsure that the icon in question will have broader use. |
Add optional arguments to
scripts/generate-icons.jsto allow custom input/output dirs to be specified. This allows the script to be re-used to generate icons in other projects, or for other purposes. Per commit notes, I'm not using a proper CLI parser because the args are so simple. This can be changed if the syntax gets more complex.The initial use case is to generate icon components for the video player app. The changes in this PR are enough for that. It would be convenient if the script was included in the package, then we could add a
package.jsonscript to run it in the downstream project.While testing this I noticed that incremental runs of ESLint and Prettier were taking a long time because caching was not enabled, so I fixed that in a separate commit.