woeps / refabricator Goto Github PK

Add a Factory, which writes the generated content to the filesystem. - one file per fabric.
Probably with a signature of factory((/*path*/ string, /*extension*/ string).

Lib.Print.error currently prints to stdout. This should be changed to stderr: prerr_endline

reported by: @Et7f3 on discord: https://discordapp.com/channels/235176658175262720/235198962498273282/676271032163631144

Currently there are no automated tests. The library (Refabricator) should have tests for each component (fabricator, refabricator, factory).

Types.fabric shall be changed to be a record: {name, fn: 'a => content} because a fabricator should already be able to name it's created fabrics. The name will be the file-path by convention.

This change will enable refabricators to implement actions depending on the fabric's name without actually calling the fabric's function. e.g for Lib.Refabricators.filterbyExtenstion() (#6)

Refabricator will be published as a library for anyone to use and build on top of it. But...

It would be great to provide a prebuilt binary for the most common use-cases but still enable devs to extend functionallity where needed without the need to compile everything over again.

There are 2 projects I know about which could help:

• ocaml_plugin
• Omod

The experience I'd currently like to look into is:

• "extension points" / "hooks" in the binary where custom code could change the binary's behaviour
• cli arg to specify a reason/ocaml file per "extension point" (note: not compiled!)

This way a dev would just implement a module for a given module type (depending on what he/she wants to customize) and pass the location of this file to the binary as a cli argument.

Questions

Which extension points would be most desirable?

Some ideas:

• customFabricator: custom implementation of a fabricator to change how data is aggregated (not sure: add ths fabricator or replace others?)
• beforeRefabricators: custom implementation of a refabricator which is run before all default refabricators
• afterRefabricators: custom implementation of a refabricator which is run after all default refabricators
• replaceRefabricators: custom implementation of a refabricator to change how data is modified
• replaceFactory: custom implementation of a factory to change how generated data is stored

Are some missing? How shall they be prioritized?

Which functionality to support through cli args and when are extension points needed?

The binary should have some cli arguments to specify options in the default setup. How far can someone get with just using cli args? And where are extension points really needed?

Having a single s as the sole difference between the two module names can be confusing for consumers of the lib.

Maybe change Lib.Refabricator to Lib.Main or something similar.

reported by: @Et7f3 on discord: https://discordapp.com/channels/235176658175262720/235198962498273282/676270530629730315

Currently bin/dune has a public_name set which makes it visible to dependent projects.

This should be removed to use the binary only for examples.

reported by: @Et7f3 on discord: https://discordapp.com/channels/235176658175262720/235198962498273282/676270530629730315

GitHub Actions running test on windows-latest yield the following error: Fatal error: exception End_of_file´ I think this originates in refabricator/lib/Fs.file2string`.

Currently concepts and goals are scattered across different issues.
Core concepts shall be added to the readme to enable readers to better grasp the meaning and goals of this project:

• extendability
• customizability
• reusable library AND pre-built binary

Probably, more details are needed.

Currently the localPath fabricator ignores any subdirectories. These shall be read in recursively.

A directory structure like the following:

mdDir
  + - subdir
  |   | 10.md
  |   + - subsubdir
  |   |   | 20.md
  | 00.md
  | 01.md   

Should yield fabrics named like (given mdDir was given as path):

• 00.md
• 01.md
• subdir/10.md
• subdir/subsubdir/20.md

The current implementation sometimes feels like a bad rough implementation of something similar to reactive streams. - so why not go the full mile and actually use an established strems library?

I'd be very much interested in some opinnions!

Some libraries I found:

• Lwt_stream
• React
• lwt-pipe
• wonka

Dependents of the library should be able to use it by the actual name.

reported by: @yawaramin on discord: https://discordapp.com/channels/235176658175262720/235198962498273282/676274036711489557

Danger of premature optimization! - Get some more datapoints before actively working on this issue.

Luv supports event loops and multithreating for crossplatform in a convenient way.

Maybe Luv could be used to improve generator performance for factories?

depends on #18
Implement new Refabricator filterByExtension, which takes a string as it's only option and returns a list of fabrics only having the given extension in it's name. (see #6)

Refactor Lib.Fabricators.md() for better reuse.
Split into:

• Lib.Fabricators.localPath() to get fabrics for all files from a local path
• Lib.Refabricator.md() to parse fabrics with the extension md in their name into md and further to html. The other fabrics will still return their unparsed strings
• Lib.Refabricators.filterbyExtenstion() to only get fabrics with a specific file extension in their name
• Lib.Refabricators.ofMd to combine the functions above

Currently links in md files are only parsed by omd and therefore don't produce correct href attributes in resulting html links.

The (re)fabricator(s) for md need to be adapted: probably just replace all links to md files with links to the same relative path but with html extension.

This should be easier after #18 is resolved. Additionally fabrics' names should be the relative file path by convention. When writing a fabric to disc the generated file shall be named according to the fabric's name, but with slashes replaced by underscores.

GitHub Action yields errors when running test on mac-latest like the following: Error: /Users/runner/runners/2.165.2/work/refabricator/refabricator/generated/p2.md.html: Operation not permitted
This error seems to come from refabricator/lib/factories.file.

I don't really know why this happens. Any idea/help is appreciated.

Add a fabricator which just takes a static string as an argument and returns a fabric.

This is especially usefull for Refabricator.between. - #27

Type: let str: Types.fabricator(string)

Add danger-js or some native equivalent to this repository to validate pull requests and automatically comment on them with warnings / errors.
E.g.: if changelog was not modified

If you know some alternative for native, please comment!

Use a logging library for (scoped) log/debug messages which can be toggled by level.
Logs was recommended.

Currently a factory returns result(unit, string).
For better console output result(list(string), list(string)) is desired.
Ok will hold a list of the fabrics' name which was processed sucessfuly by the factory.
Error will hold a list of tuples holding fabrics name and a list of errors per fabric.

A possible feature came up on discord:
Parse rei files:

• convert comments formatted in markdown to html
• parse the definitions
• enable linking between different definitions and pages / fabrics
• extend binary

Refabricator.between should be changed to only take fabrics as it's arguments.
This enables to not just use static strings for before and after arguments, but any data which can be generated by a fabricator.

Resulting type:

type betweenOps = {before: Types.fabric, after: Types.fabric};
let between: Types.refabricator(betweenOps);

Also relevant: #28

Use Refabricate to generate GitHub Pages.
Readme could be used for a start. More Infromation can be added over time.

Add a factory which puts all generated files on a ftp server.

Rename binary from Ssg.exe to refabricate.exe.

Automatically handle (GitHub) release:

• create release for a new version tag
• add binary (bin/refabricate.exe) for each platform separately - for standalone usage
• add generated docs
• add sources (github default behaviour)

Currently every ci invocation for windows target fails at test step.

More information / research needed.

Windows ci fails test step with:

Fatal error: exception End_of_file

Here is missing a close channel. Not sure this is the real problem.

Implement a fabricator which fetches a directory from a git server.