What we want aunty to do
The most important reason for aunty to exist is to provide and facilitate common ways of working for editorial developers at ABC News. The key benefit of this is that we can, usually, pick up someone else's work at short notice and get it built and deployed.
It ensures a familiar base on which custom elements and components are built
Makes sure projects are deployed in a consistent and familiar way and eliminates the need for manual handling of production assets
There are three broad concerns aunty facilitates:
- Scaffolding new projects
- Providing a local dev server
- Build and deploy to production and preview environments
All of these are handled by third party tools under the hood but, importantly, aunty abstracts those details away with two main purposes:
- Ensure the tools are used consistently in ABC News projects, and
- Provide a simple, consistent and familiar set of commands for developers to use.
Through re-developing aunty we hope to make use of more modern and capable tooling under the hood while retaining the benefits of having a single, simple, consistent and familiar tool.
What is the scope we want aunty to handle in terms of project types?
There are lots of things aunty could do, but we need to be clear about where the line is drawn (at least initially — we also want an extensible architecture so new project types can be accommodated). Thing currently supported get a ✅ others we should think about.
- ✅ in-page things (embeds, anything that uses mounts or decoys)
- ✅ iframe embeds
- ❓ native web components
- ❓ ai2html
- ❓ utility libraries
- ❓ component libraries
- ❓stand alone web apps
1. Scaffolding
Currently, aunty support scaffolding both components and projects and leverages Yeoman to do the heavy lifting.
Question: What types of scaffolding are most commonly used?
- Does anyone use the component scaffolding?
- Which project types do people use?
- Are there any other project types we should consider supporting (e.g. ai2html)?
Aside from just basic templating, scaffolding has a few other purposes:
- Setting up common coding standards through things like linter, code formatting, and typescript configurations.
- Applying default licensing
- Providing other common configuration like .gitignore and NPM scripts for dev, build and deploy.
- Setting up ABC environment specific tooling like dev-proxy.
It could also do things like provide editor configurations including workspace settings and development containers.
What are the potential options for scaffolding?
- Continue to use Yeoman
- Look at other options: degit, npm init,
- How could we provide a simpler way to maintain templates? Is that even an issue?
2. Development server
For development server (and build) there's reasonably broad consensus that vite is a good solution. It has a robust plugin API that we should be able to use to extend or customise it's functionality to fit our needs. Additionally, most of our work these days uses Svelte, which also uses vite.
Other considerations to flesh out:
- Handling TLS/SSL on for local development
3. Build and deploy
This is, as the heading suggests, two distinct concerns — though they're fairly tightly coupled. The build output must work in the deployment environment.
This is also the area which is most unknown right now. Realistically we need to build a solution for the existing scenario which means deployed assets go to Content FTP.
However there's an effort underway to improve editorial development infrastructure which likely involves a deployment process that runs on GitLab's pipelines and deploys to an S3 bucket. The details are unknown, so for now we need to continue to target the existing solution.
What we want aunty to do
The most important reason for aunty to exist is to provide and facilitate common ways of working for editorial developers at ABC News. The key benefit of this is that we can, usually, pick up someone else's work at short notice and get it built and deployed.
It ensures a familiar base on which custom elements and components are built
Makes sure projects are deployed in a consistent and familiar way and eliminates the need for manual handling of production assets
There are three broad concerns aunty facilitates:
All of these are handled by third party tools under the hood but, importantly, aunty abstracts those details away with two main purposes:
Through re-developing aunty we hope to make use of more modern and capable tooling under the hood while retaining the benefits of having a single, simple, consistent and familiar tool.
What is the scope we want aunty to handle in terms of project types?
There are lots of things aunty could do, but we need to be clear about where the line is drawn (at least initially — we also want an extensible architecture so new project types can be accommodated). Thing currently supported get a ✅ others we should think about.
1. Scaffolding
Currently, aunty support scaffolding both components and projects and leverages Yeoman to do the heavy lifting.
Question: What types of scaffolding are most commonly used?
Aside from just basic templating, scaffolding has a few other purposes:
It could also do things like provide editor configurations including workspace settings and development containers.
What are the potential options for scaffolding?
2. Development server
For development server (and build) there's reasonably broad consensus that vite is a good solution. It has a robust plugin API that we should be able to use to extend or customise it's functionality to fit our needs. Additionally, most of our work these days uses Svelte, which also uses vite.
Other considerations to flesh out:
3. Build and deploy
This is, as the heading suggests, two distinct concerns — though they're fairly tightly coupled. The build output must work in the deployment environment.
This is also the area which is most unknown right now. Realistically we need to build a solution for the existing scenario which means deployed assets go to Content FTP.
However there's an effort underway to improve editorial development infrastructure which likely involves a deployment process that runs on GitLab's pipelines and deploys to an S3 bucket. The details are unknown, so for now we need to continue to target the existing solution.