Goal
| User story |
| As a contributor to the website, |
| I want to have a shorter, more standardized process for landing page builds and viewing changes |
| so that I can more quickly perform these tasks, and thus have a higher probability of doing them for verifying even minor changes. |
How?
Context
I'm reading through the handbook and, in addition to fxiing tpyos, I've noticed a few rather step-intensive processes that, while it's great that they're spelled out, look like they could be automated a bit more. Landing page generation seems to be one of those.
Additionally, coming from other environments relying on Node (React/Vue/Angular/Nest/NestJS), the convention at this point seems to be to have package.json contain commonly used scripts, rather than needing to globally install another tool. While this isn't my first Sails project I've touched, it's been awhile, and my guess is that semi-random contributors won't have that set up, so having a workflow that uses npm scripts instead will increase the chance that a potential contributor (internal primarily-Golang or external) validates things locally ("run npm i and then run npm run start-dev rather than "install sails globally or use this ugly command").
The first couple of checklist items should be quick handbook fixes...just wanted to make sure Digital Experience folks agree that they'd be a good idea...while the third item should likewise not be too bad even though it's more than just a docs update.
Fourth item should probably be split into a different issue but I'm including it here to show a natural progression of making life easier, depending on how often landing pages are/are expected to be created, as the customers for those changes are 100% internal so frequency of use may not be high enough for process cleanup to be relevant.
Goal
How?
npm run xyz, removing the mention of the latter later in the pageContext
I'm reading through the handbook and, in addition to fxiing tpyos, I've noticed a few rather step-intensive processes that, while it's great that they're spelled out, look like they could be automated a bit more. Landing page generation seems to be one of those.
Additionally, coming from other environments relying on Node (React/Vue/Angular/Nest/NestJS), the convention at this point seems to be to have package.json contain commonly used scripts, rather than needing to globally install another tool. While this isn't my first Sails project I've touched, it's been awhile, and my guess is that semi-random contributors won't have that set up, so having a workflow that uses npm scripts instead will increase the chance that a potential contributor (internal primarily-Golang or external) validates things locally ("run npm i and then run
npm run start-devrather than "install sails globally or use this ugly command").The first couple of checklist items should be quick handbook fixes...just wanted to make sure Digital Experience folks agree that they'd be a good idea...while the third item should likewise not be too bad even though it's more than just a docs update.
Fourth item should probably be split into a different issue but I'm including it here to show a natural progression of making life easier, depending on how often landing pages are/are expected to be created, as the customers for those changes are 100% internal so frequency of use may not be high enough for process cleanup to be relevant.