Options for @scullyio/init:markdown and @scullyio/init:blog

[d-koppenhagen]

🧩 Feature request

When generating a new blog it would be great to have some more Options:

ng g @scullyio/init:blog <options>

Description

I think it would be good to have at least three more configuration options when creating a blog, to define the basic module name, the source directory for the blog content files and the route for availability of the static pages.

Describe the solution you'd like

• baseName - The basic Name and prefix that's used for the BlogModule and BlogComponent, etc. This should be set to blog by default (with this it wouldn't break the current behavior)
• sourceDir - This parameter should define the source directory for the blog files (*.md). It should be set to blog by default (with this it wouldn't break the current behavior)
• route - This parameter should define the route under which the blog sites are available. It should be set to blog/:slug by default (with this it wouldn't break the current behavior)

A further benefit is that it would allow one to create multiple different blog areas:

ng g @scullyio/init:blog
ng g @scullyio/init:blog --baseName=“project” --sourceDir=“projects” --route=“project/:slug”

This functionality would also affect the generation of new entries:

ng g @scullyio/init:post --name="This is a new blog post"  # use `blog` by default, no breaking change
ng g @scullyio/init:post --name="This is a new project description" --target="project" # matches with `sourceDir`

What do you think?

[SanderElias]

@d-koppenhagen, @xmlking,
The blog option is meant to be an easier version of the post option. with set folders and component name. Its to be used for quick demo's, and probably covering the most common use-case.
I'm fairly sure that @jorgeucano will rewrite the 'blog' option to use the 'post' option internally.

We should add those options to the ng g @scullyio/init:post, and leave the blog option as simple as possible.

[d-koppenhagen]

Ah okay, this seems legit. Probably it should just be documented a bit more clear in the docs.

[d-koppenhagen]

But we still need this options in ng g @scullyio/init:markdown don't we? I mean for choosing a specific dir etc. And not touching ng g @scullyio/init:blog

[d-koppenhagen]

So my proposal would be the following:

• extend ng g @scullyio/init:markdown with the following options:
  • sourceDir lets one specify a name for the markdown sources
  • adjust the current name option: The name should be used for the module. The name option should be used for the source dirctory as well but just if no sourceDir option is provided
  • route this parameter should define the route under which the module is available.
• extend ng g @scullyio/init:post with the following options:
  • target="project" - matches with one of the available sourceDir previously generate by using ng g @scullyio/init:markdown or ng g @scullyio/init:blog. The best would be to let the user also choose from a prompt from the configured source dirs.

What do you think?

[xmlking]

in most cases, all posts in a blog have consistent metadata. It would be nice to have an option to specify one or more templates in scully.config.js, instead of default template.
Then we should be able to overwrite them with command line parameters

ng g @scullyio/init:post --thumbnail=assets/images/blog/sumo-blog3.jpg --keywords=alpha,beta --published

for example

---
title: blog 1
description: This is the first demo blog in this sample.
thumbnail: assets/images/blog/sumo-blog2.jpg
keywords:
  - PWA
  - Angular
  - Service Worker
  - SSR
  - Push Notification
author: Sumo Demo
mail: sumo@demo.com
published: true
publishedOn: 2019-07-24
---

# blog 1

## its a wild world after all

    ```typescript
    console.log('amazing');
    ```

Related information [blog-2](/home/blog/blog-2)

[site-map](/home/blog)

[d-koppenhagen]

@Villanuevand can you have a look at the WIP PR?

[jorgeucano]

@SanderElias we support all of this meta-tags ?

[d-koppenhagen]

I think the meta tags are just passed through and available as key-value-pair in the result. When I used scully I added some very custom meta data and it worked still. I could request them via ScullyRouteService

[d-koppenhagen]

But I think we should discuss the suggestion from @xmlking a bit more like:

• What meta tags should be supported by the schematic?
• could't this lead into a bunch of options one will add calling the schematic?
• I can image there are users that aren't using the meta section in markdown at all (image a very simple blog).
• A meta tag can be very custom so probably we need to focus on the really important ones?
• Don't I have to touch the generated file anyway (to fill it with content)?
• I can image that the real purpose is the following: I am a user an I have a blog. I will process some kind of meta data (doesn't matte which one and if they are very specific or not). My goal is now hwen creating anew post that all meta data are prefilled (not with the target data but with some defaults). So why whould we add a default config file? So here is my concrete suggestions:

ng g @scullyio/init:post --metaConfig="meta.config.json"

and then the following config will be parsed (just as an example):

{
  "thumbnail": "assets/images/default.jpg",
  "author": "John Doe",
  "mail": "John.Doe@example.com",
  "keywords": [
    "scully"
    "angular"
  ],
  "language": "en"
}

And finally our meta blog added to a new blog-post would look like this:

---
title: my-blog-post
thumbnail: assets/images/default.jpg
author: John Doe
mail: John.Doe@example.com
keywords:
  - angular
  - scully
language: en
---

whereas the title will be used from the config if set, if no, use the name.

What do you think?

[d-koppenhagen]

Or maybe as part of the scully.config.js configuration file? And then there would be no option flag necessary as the options will be used when available in the config file... think 🤔 I think this would be even better.

[xmlking]

I like the idea of having my default meta tags as JSON in scully.config.js and then having an optional flag(key, value pairs) for overwrite...

ng g @scullyio/init:post  --metaOverwrite="published=false, title=My Blog1" 

[d-koppenhagen]

I still don’t know about those flags. The validation of such an option with complex configuration seems to be tricky to me and not really handy.
As I wrote before: don’t you have to adjust the post anyway after setting it up? So is it really worth it to remember the syntax passing a KVP into the option and writing it on the command line easier/better compared to setting it up using the default meta config and just adjusting it as you will adjust the post file anyway and fill it with content?

[SanderElias]

I like the idea of having a 'default', However, it should be just a string (can be a multiline string)
In there the app-owner can set his favorite defaults, and what he needs.
as @d-koppenhagen stated, the blog user needs to touch the file anyway, they want to put in their content, otherwise, there is no point to the whole exercise, to begin with.
By keeping the setting a string, it will not be that complex to handle.

Hmm, come to think about it. I think it would make sense to create a file with defaults. something like:
defaultBlogHeader.yaml:

title: my-blog-post
thumbnail: assets/images/default.jpg
author: John Doe
mail: John.Doe@example.com
keywords:
  - angular
  - scully
language: en

Then the schematic can just read this as a string and inject it in the result.

ng g @scullyio/init:post --metaDataFile='defaultBlogHeader.yaml" title="whatEver"

[d-koppenhagen]

I like this suggestion!

[d-koppenhagen]

@SanderElias here it is: df7500f