Initial documentation

.editorconfig

@@ -4,7 +4,6 @@
 
 root = true
 
-
 [*]
 end_of_line = lf
 charset = utf-8

.eslintignore

@@ -13,6 +13,7 @@
 # misc
 /coverage/
 !.*
+.eslintcache
 
 # ember-try
 /.node_modules.ember-try/

.eslintrc.js

@@ -1,54 +1,53 @@
+'use strict';
+
 module.exports = {
   root: true,
   parser: 'babel-eslint',
   parserOptions: {
     ecmaVersion: 2018,
     sourceType: 'module',
     ecmaFeatures: {
-      legacyDecorators: true
-    }
+      legacyDecorators: true,
+    },
   },
-  plugins: [
-    'ember'
-  ],
+  plugins: ['ember'],
   extends: [
     'eslint:recommended',
-    'plugin:ember/recommended'
+    'plugin:ember/recommended',
+    'plugin:prettier/recommended',
   ],
   env: {
-    browser: true
-  },
-  rules: {
-    'ember/no-jquery': 'error'
+    browser: true,
   },
+  rules: {},
   overrides: [
     // node files
     {
       files: [
         '.eslintrc.js',
+        '.prettierrc.js',
         '.template-lintrc.js',
         'ember-cli-build.js',
         'testem.js',
         'blueprints/*/index.js',
         'config/**/*.js',
         'lib/*/index.js',
-        'server/**/*.js'
+        'server/**/*.js',
       ],
       parserOptions: {
-        sourceType: 'script'
+        sourceType: 'script',
       },
       env: {
         browser: false,
-        node: true
+        node: true,
       },
       plugins: ['node'],
-      rules: Object.assign({}, require('eslint-plugin-node').configs.recommended.rules, {
-        // add your custom rules and overrides for node files here
-
+      extends: ['plugin:node/recommended'],
+      rules: {
         // this can be removed once the following is fixed
         // https://github.com/mysticatea/eslint-plugin-node/issues/77
-        'node/no-unpublished-require': 'off'
-      })
-    }
-  ]
+        'node/no-unpublished-require': 'off',
+      },
+    },
+  ],
 };

.gitignore

@@ -12,6 +12,7 @@
 /.env*
 /.pnp*
 /.sass-cache
+/.eslintcache
 /connect.lock
 /coverage/
 /libpeerconnection.log

.prettierignore

@@ -0,0 +1,21 @@
+# unconventional js
+/blueprints/*/files/
+/vendor/
+
+# compiled output
+/dist/
+/tmp/
+
+# dependencies
+/bower_components/
+/node_modules/
+
+# misc
+/coverage/
+!.*
+.eslintcache
+
+# ember-try
+/.node_modules.ember-try/
+/bower.json.ember-try
+/package.json.ember-try

.prettierrc.js

@@ -0,0 +1,5 @@
+'use strict';
+
+module.exports = {
+  singleQuote: true,
+};

.template-lintrc.js

@@ -1,5 +1,5 @@
 'use strict';
 
 module.exports = {
-  extends: 'octane'
+  extends: 'octane',
 };

.travis.yml

@@ -1,10 +1,9 @@
 ---
 language: node_js
 node_js:
-  - "8"
+  - "10"
 
-sudo: false
-dist: trusty
+dist: xenial
 
 addons:
   chrome: stable
@@ -23,6 +22,4 @@ branches:
     - master
 
 script:
-  - npm run lint:hbs
-  - npm run lint:js
   - npm test

app/app.js

@@ -1,7 +1,7 @@
 import Application from '@ember/application';
 import Resolver from 'ember-resolver';
 import loadInitializers from 'ember-load-initializers';
-import config from './config/environment';
+import config from 'empress-documentation/config/environment';
 
 export default class App extends Application {
   modulePrefix = config.modulePrefix;

app/router.js

@@ -1,10 +1,9 @@
 import EmberRouter from '@ember/routing/router';
-import config from './config/environment';
+import config from 'empress-documentation/config/environment';
 
 export default class Router extends EmberRouter {
   location = config.locationType;
   rootURL = config.rootURL;
 }
 
-Router.map(function() {
-});
+Router.map(function () {});

config/ember-cli-update.json

@@ -0,0 +1,17 @@
+{
+  "schemaVersion": "1.0.0",
+  "packages": [
+    {
+      "name": "ember-cli",
+      "version": "3.25.2",
+      "blueprints": [
+        {
+          "name": "app",
+          "outputRepo": "https://github.com/ember-cli/ember-new-output",
+          "codemodsSource": "ember-app-codemods-manifest@1",
+          "isBaseBlueprint": true
+        }
+      ]
+    }
+  ]
+}

config/environment.js

@@ -1,6 +1,6 @@
 'use strict';
 
-module.exports = function(environment) {
+module.exports = function (environment) {
   let ENV = {
     modulePrefix: 'empress-documentation',
     environment,
@@ -14,8 +14,8 @@ module.exports = function(environment) {
       },
       EXTEND_PROTOTYPES: {
         // Prevent Ember Data from overriding Date.parse.
-        Date: false
-      }
+        Date: false,
+      },
     },
 
     APP: {

config/targets.js

@@ -3,16 +3,17 @@
 const browsers = [
   'last 1 Chrome versions',
   'last 1 Firefox versions',
-  'last 1 Safari versions'
+  'last 1 Safari versions',
 ];
 
-const isCI = !!process.env.CI;
+const isCI = Boolean(process.env.CI);
 const isProduction = process.env.EMBER_ENV === 'production';
 
 if (isCI || isProduction) {
   browsers.push('ie 11');
 }
 
 module.exports = {
-  browsers
+  browsers,
+  node: "current",
 };

ember-cli-build.js

@@ -2,7 +2,7 @@
 
 const EmberApp = require('ember-cli/lib/broccoli/ember-app');
 
-module.exports = function(defaults) {
+module.exports = function (defaults) {
   let app = new EmberApp(defaults, {
     fingerprint: {
       extensions: ['js', 'css', 'map']

guides/empress-blog/custom-templates.md

@@ -0,0 +1 @@
+TODO

guides/empress-blog/ghost-templates.md

@@ -0,0 +1 @@
+TODO

guides/empress-blog/index.md

@@ -0,0 +1 @@
+TODO

guides/empress-products/index.md

@@ -0,0 +1,38 @@
+There are a few different ways to define the similarities between Empress Products. We could take a historical approach and follow the innovations and how they were shared between the products after they were discoverd, or we could create a grid that compared each feature in each Empress Product like a Software as a Service pricing page.
+
+I think a good way to start is to list out every official Empress Project and then explain the set of things that is common about each of products. There may be some fundemental differences between Empress Projects but there are always some core fundemental similarities.
+
+## List of Empress Products
+
+| Product      | Link                                     | Status | Exmple Site    |
+| ------------ | ---------------------------------------- | ------ | -------------- |
+| empress-blog | https://github.com/empress/empress-blog/ | Stable | [The Ember Blog] |
+|              |                                          |        |                |
+
+from talk:
+- compare to starters - nit forking - not updates
+- list of products (grouped by stability?)
+-  
+
+section about architecture
+host app - empty shell - apart from ultimately markdown
+system addon - creates a set of default content using blueprints
+template addon - just html and css - swap templates by chaning a single dependency
+
+npm init empress-blog-template - talk about template builders
+
+
+
+
+
+1) you should have an extremely fast "quick start"
+if you have a look at any of the readmes there is usually a quickstart of 2 or 3 lines that can get you started with a docs site with an example set of docs ready to go :thumbsup:
+2) Markdown is the majority way to actually write the docs
+this is intended to be a nice easy onramp for anyone wanting to participate, especially with field-guide because the code samples are "just Markdown code snippets" and you don't have to do anything special to get them to work
+3) there needs to be a separation between the "brains" of the product and the "template"
+this is why you see things like field-guide and field-guide-default-template and you can theoretically have any number of templates that provide some style. This may seem like it's not high-order enough to be part of the philosophy but it's extremely key in the way that everything works because you essentially have a public api between the brains addon and the template addon
+4) you need to be able to download content dynamically
+again this may seem odd to add to the philosophy list but it means that we're not doing any of this "pre compiling templates" solutions that some people have done to solve some of the more difficult problems with dynamic template rending
+because of (2) I have been thinking that the API solution might not actually be something that dynamically loads API docs (like ember-cli-addon-docs) but instead it could just be a process that takes your code as in input and outputs Markdown (in a particular structure) that is pre-populated with your ESDocs or something
+that way you can intervene and edit things that didn't work out right, but we would have a process where you could verify if your API docs are up to date during build time
+alternatively we could have a set of components that could "render" the API docs, but again because of (4) that would mean that the API docs processing system would need to output consumable JSON (and in fact everything Empress is using JSON:API so that could be the common format here)

guides/index.md

@@ -1,5 +1,15 @@
-Welcome to your brand new Guidemaker Guides 🎉
+Welcome to the Empress documentation. This is here to give you an overview of Empress, list some of the official _Empress Products_ that are out there and hopefully give you an idea of the general architecture of Empress.
 
-## Let's start editing
+There will also be some more in-depth guides on how to do things in Empress, like how to write templates for each of the Empress products, or how to add search capability, and other more advanced topics.
 
-You should be able to start editing the files under `guides/` now to produce your documentation. Don't forget to checkout [the Editing Guide](./getting-started/editing/) to know how to set things up!
+Also remember that this is **living documentation** so if you ever want to suggest an edit you can click the pencil icon in the top right of any page or you can make a "documentation request" by [opening an issue on the GitHub page](https://github.com/empress/documentation).
+
+## What is Empress
+
+Empress is [Ember.js](https://emberjs.com)' answer to the JAMStack. The name is inspired by VuePress and is a combination of Ember and Press, and is why we have one of the [coolest Zoey mascots](https://emberjs.com/mascots/#empress) out there!
+
+Because Ember is an all-in-one platform that already had a robust Server-Side Rendering (using [FastBoot](https://ember-fastboot.com/)) and Server-Side Generation (using [prember](https://github.com/ef4/prember)) we didn't need any new low-level building blocks to allow people to be able to make their apps work for SSR or SSG.
+
+Instead of being a low-level building block, Empress is a set of "products" that are each designed to serve a particular use-case very well. Each Empress product shares some core architectural decisions so they should all feel quite familiar, and they are all equally focused on providing the best possible solution for maximising SEO.
+
+In the next section I will go into more detail on what it means to be an Empress Product and list the current "official" products.

guides/pages.yml

@@ -1,14 +1,23 @@
-- title: "Guides and Tutorials"
+- title: "Introduction"
   url: 'index'
-  skip_toc: true
   pages:
-    - title: "Guides"
+    - title: "Overview"
       url: ""
 
-- title: "Getting Started"
-  url: 'getting-started'
+- title: "Empress Products"
+  url: 'empress-products'
+  pages:
+    - title: "What is an Empress Product"
+      url: "index"
+    - title: "The Architecture of an Empress Product"
+      url: "architecture"
+
+- title: "Empress Blog"
+  url: 'empress-blog'
   pages:
     - title: "Introduction"
       url: "index"
-    - title: "Editing"
-      url: "editing"
+    - title: "Custom templates"
+      url: "custom-templates"
+    - title: "Porting a Ghost template"
+      url: "ghost-templates"