functionhaus / archivist Goto Github PK

Parser should accept an option that allows the user to either sort by an attribute, or pass an anonymous function that will sort articles with custom logic.

Testing is currently only being performed with a single article fixture. Let's add a few different article examples in sub-directories to ensure that attribute lists are being parsed and compiled as expected.

Tag the published commit for all published Archivist package versions and push the tags to github.

Add functionality for storing images at priv/images in the target image directory, and parsing available image filenames.

Add some kind of functionality for allowing users to create a constrained list of author names, allowing only those specific author names to be used. Articles with author names that do not exist within the constrained list should throw warnings at compile-time.

Add generator tasks for creating pre-structured templates for Arcdown files without having to reference the correct Arcdown format.

Errors should be thrown at compile time if compilation does not succeed at parsing articles from the target format (Arcdown by default).

Add a Series struct for defining attributes for series entities.

We need some kind of functionality for allowing users to create a constrained list of tags for each application, allowing only certain tags to be used within articles. Articles that apply tags that do not exist within the constrained list should throw errors at compile-time.

The README is currently unclear on whether content is parsed as Markdown by default. This should be clarified to explain the current state of the Markdown implementation.

The best design pattern for using Archivist seems to be installing it in an intermediary mix library (some_app_blog etc.), collecting the archived articles and image there, and then including the intermediate mix library in the final target application. This approach separates clutter from commit messages related to the content into an archive/content-specific repository, and allows the consumer library to focus just on commits for code. We need documentation in the README and/or Wiki to outline this process and how it needs to be setup, both as an intermediate library and in the final destination (including using Plug.Static to serve image assets).

The article_parser Archive flag currently is unused and is a placeholder. We need to inject this into the article parsing workflow so that content is actually parsed using the module or anonymous function stored in the article_parser setting.

Currently the archive_dir option has to change if the application flag is used to utilize a 'remote-style' archive. This seems like an antipattern. archive_dir should refer only to the name of the archive directory, and the archive_root should be the path to the entire archive entity.

Add README example to show how hierarchical topics are parsed and what the output of multiple topics directories will look like.

README and docs currently outline a basic workflow for using Archivist in the same Mix library/application in which the archive content is being held, but we need to outline the process of referencing content from an external OTP application being used as a dependency.

Let's setup an automated testing pipeline for Archivist on CircleCI.

Archivist should be able to generate a series_id value for existing articles in order to include them in an article series

Assets directories for articles and images are currently being resolved relative to the current working directory (Path.relative_to_cwd) but should be resolved to the priv dir for the target BEAM application that is housing the archive assets (Path.join(:code.priv_dir(:some_app), "archive")).

We need to add an archive option to determine which app is housing the target assets, either instead of the current solution or as an override to the existing approach.

Need to add a CircleCI widget to the README once the CI pipeline is established.

Currently Topics and sub-topics are being parsed as single-level entities and mixed together without any enforced hierarchy. The topics parser should retain the hierarchy set forth in all articles and infer topics and sub-topics based on the hierarchy established in the articles.

Add support for using a set of articles written as a series. This may be an additional featureset for an Archivist.Article struct or implemented directly in Arcdown.Article.

Add a guide in the Wiki for mounting archive images to a static content path in Phoenix.

Articles and images are currently stored in separate directories in the priv dir, which could get messy for applications that already have several directories under priv. By default these should be grouped into a top-level priv/archive dir to create less clutter in the priv dir.

Errors should be thrown at compile time if multiple articles share the same slug.

Articles should be parsed as Markdown with Earmark by default. Setting the content_parser flag to nil should completely ignore parsing article content.

Generated Arcdown files should automatically be assigned a uuid value to identify the article.

Currently Archivist only works if it is implemented as a dependency in the application where the content and images also reside. We need to add functionality to allow the user to declare which
OTP app to fetch the content from so that content paths are correctly resolved to the target directory, not just the current working directory.

Add some kind of functionality for allowing users to create a constrained list of topics and sub-topics, allowing only those specific topics and sub-topics to be used by articles. Articles that apply topics and sub-topics that do not exist within the constrained list should throw errors at compile-time.

Add negative test cases for parsing article content without using a content parser.

Currently topics are being parsed based on the directories and sub-directories used to store the articles within the archive. The user should have the option to ignore those directory paths and instead use only the topic hierarchies listed within the article arcdown content itself.