• Tooling allows for building and deploying to S3 using Cloudfront for the CDN and SSL
• Dev, stage and prod version
• Dev runs locally and stage runs on S3 with a Lambda@Edge function to manage basic auth
• Includes concat, minify and replace JS, CSS

Apply docker compose to the dockercompose.yml file in .joy/docker to start, stop and restart a docker stack. Stage specific variables would be extracted from .joy/config.json based on the stage identifier.

joy init --template {template-name}

• Copies files and recreates same folder structure as templates/{template-name}
• If template parameter is omitted then use templates/default
• Templates implement suitable core files including but not limited to:
  • package.json
  • README.md
  • .dockerignore
  • .editorconfig
  • .eslintrc.json
  • .gitignore
• A suitable .joy folder is created with:
  • config.json
  • docker/{type}.dockerfile
  • docker/docker-compose.yml
• The package manager (e.g. npm, composer, nuget, etc) is run to install packages

I think stdout is good for now, perhaps a flag or two down the road to export to a couple basic file types.

Originally posted by @webdivelement in #9

Deploys the current project to the named stage. Variables are retrieved from .joy/config.json based on the stage. The configuration also defines the type of deployment (e.g. S3, Ionic, etc)

That is, without other Joy dependencies so that it can be repurposed into a Lambda function

Apply docker build to the image defined in .joy/docker and prefixed with name.

e.g. container build -n mysql applies to .joy/docker/mysql.dockerfile

Thoughts so far:

• Since initing happens once at the beginning of the project we can probably get away with shelling out to npx yo so we don't need to include Yeoman in our base build.
• We can publish joy-{template}-generators to NPM so they can live in their own repos
• Yeoman has it's own CLI for prompting for variables to expand into templates so we don't need to build that part.

Description

This issue is being used to test git-ticket

• Helps abstract the underlying implementation from Joy
• Helps with second level commands

Executes docker run {image} -d against the dockerfile prefixed by name. Parameters such as port and volume mappings are obtained from .joy/config.json using the name and stage as reference points.

The C4 architectural model works in a descending hierarchy of context, containers, components and code. Following this we should be able to assign a namespace to a project consisting of multiple repositories where each repository is implementing containers. For a simplified example, a typical web app context would include the web app and the api containers. The api container, would include a NodeJs and MongoDb component.

By defining this relationship is some sort of meta language in config.json (or perhaps one level higher) we can simplify the command processor and developer experience (DX). E.g. If a developer is working in a container with a single component then there should be no need to specify the component in every joy build command. joy build would default to the only available component. Similarly we should be able to assign meaningful aliases to components making joy build spongebob a valid command. There can even be reserved words to facilitate commands like joy build all that would build all components across all contexts.

The original vision for the generator was to behave more like a transformer. E.g. Given a set of static HTML files and data, transform to the desired output. I realize now that this differs from a static site generator that relies on a lot more custom code.

In all fairness, the transformer would probably only work for simple sites, blogs, one-pagers, etc. But that's the sweet spot I wanted it to fill since those small projects often take up a large amount of time in that they have the same lengthy provisioning phase.

With a site transformer, anyone with basic HTML/CSS chops can whip up a decent looking site. Then, with the aid of a handful of custom HTML elements, data can be used to transform some of the site. The custom elements I had in mind would implement logical branching, looping and content replacement. Looping would work intra and inter page (e.g. create a repeating list inside a page, and create multiple pages).

The transformer would also take care of minification, concatenation, rewriting script references, adding cache busters, etc.

Let's discuss the merits of a transformer vs generator.

Not every project will require every plugin. We need a way to install a minimal set of plugins during init and then add additional plugins, automatically, only when they are first requested by the framework.

There maybe something in NPM that already does this. If not, maybe some interesting hackery of the require pipeline.