npmpackage.info

Gathering detailed insights and metrics for @acmedinotech/docproc

Other packages similar to @acmedinotech/docproc

docproc

1.2.0

A document processing pipeline

daq-proc

8.0.0

Simple document processor to make search running in the browser and node.js a little better. Supports 50+ languages. Removes stopwords (smaller index and less irrelevant hits), extract keywords to filter on and prepares ngrams for auto-complete functional

@acmedinotech/form-state

0.0.6

an intuitive approach to dynamic forms and application state.

@acmedinotech/dynform-react

0.0.7

managed stateful, nested form data with ease and efficiency

Gathering detailed insights and metrics for @acmedinotech/docproc

@acmedinotech/docproc

a fully extensible lexer-parser document processor with [enhanced] markdown support

0.8.14

GPL-3.0

TypeScript

1,171 1.7

Installations

npm install @acmedinotech/docproc

Pull Requests

Open

0

Total

20

Closed

0

Merged

20

Issues

Open

0

Total

0

Closed

0

Releases

Unable to fetch releases

Developer

kaisershahid

Developer Guide

BETA

Module System

CommonJS

Min. Node Version

Typescript Support

Yes

Node Version

12.20.0

NPM Version

6.14.8 Statistics

29 Commits

2 Watching

3 Branches

1 Contributors

Updated on 15 Jan 2021

Languages

TypeScript (98.89%)

JavaScript (0.71%)

Shell (0.4%)

Total Downloads

Cumulative downloads

Total Downloads

1,171

Last day

Compared to previous day

Last week

Compared to previous week

Last month

66.7%

Compared to previous month

Last year

-59.2%

119

Compared to previous year

Daily Downloads

Weekly Downloads

Monthly Downloads

Yearly Downloads

Dependencies

@types/argparse @types/node argparse ts-node typescript

Dev Dependencies

@types/chai @types/cheerio @types/mocha awesome-typescript-loader chai cheerio fs mocha path prettier webpack webpack-cli

Versions

docproc

An extensible document processor, suitable for human-friendly markup. Take it for a drive with your Markdown document of choice:

docproc path/to/your/file

Architecture Overview

First, let's talk document structure. Human-readable docs are linear, and they're typically organized in groups (blocks). The blocks themselves contain inline data or sub-blocks.

## html blocks at different levels

<html>
    <div><b>bold</b></div>
</html>

## markdown

> blockquote **bold**

normal paragraph

The basic approach to all solid document processors is that they use a lexer-parser pattern to break the doc down into its smallest part then sequentially put them back together (in our case, as blocks with inline text).

docproc isn't any different there. What docproc aims to do is create a pattern for configuring lexeme detection and block/inline handling. Once you get a sense for how these pieces fit it should make writing your own processor easy.

High Level Architecture

docproc makes no assumption about what you're trying to process, but it does come with a Markdown (CommonMark) plugin and DinoMark plugin, which enhances CommonMark with more dynamic processing capabilities.

How it Works (High Level)

Let's use the following snippet of Markdown as our reference:

1> **blockquote**
2
3paragraph _**bold italic**_

To start, we need to specify the following lexemes:

>
(space)
**
_
\\n

Anything that isn't explicitly identified is grouped together and emitted as their own lexemes.

We'll also need to build two block handlers:

blockquoteHandler will only accept lines beginning with >. If there are 2 consecutive newlines, the blockquote handler is done.
paragraphHandler accepts anything. Like blockquote, it also terminates after 2 consecutive newlines.

Each instance of a block has its own handler instance.

Finally, we'll need to build two inline handlers:

boldHandler starts and stops ** and allows embedded formatting
italicHandler starts and stops _ and allows embedded formatting

Follow the Tokens

Let's trace how each token changes the state of the parser, starting at the block level:

>
- blockquoteHandler can accept and is set as current handler
, **, blockquote, **
- all accepted by blockquoteHandler
\\n, \\n
- blockquote done, no longer current handler
paragraph
- paragraphHandler can accept and is set as current handler
_, **, bold, , italic, **, _
- all accepted by paragraphHandler

Pretty simple so far. Now let's look within the block and see what happens with the inline tokens. I'll use the paragraph handler:

_
- matches an inline handler. it'll take all tokens until another _, but since it allows embedding other formatting, it'll first defer the tokens to specific handlers if they exist
- stack: [italicHandler]
**
- matches an inline handler, which nests and defers
- stack: [italicHandler, boldHandler]
bold, , italic
- goes into boldHandler
**
- boldHandler is popped
- stack: [italicHandler]
_
- italicHandler is popped
- stack: []

When you turn the document into a string, you get all the pieces back, assembled from fragments of HTML returned from the different handlers.

That's basically it! You can see it all put together in readme.example.ts

Take a deeper dive:

No vulnerabilities found.

10

Binary-Artifacts

Determines if the project has generated executable (binary) artifacts in the source repository.

10

License

Determines if the project has defined a license.

0

Maintained

Determines if the project is "actively maintained".

0

Code-Review

Determines if the project requires human code review before pull requests (aka merge requests) are merged.

0

CII-Best-Practices

Determines if the project has an OpenSSF (formerly CII) Best Practices Badge.

0

Security-Policy

Determines if the project has published a security policy.

0

Fuzzing

Determines if the project uses fuzzing.

0

Branch-Protection

Determines if the default and release branches are protected with GitHub's branch protection settings.

0

SAST

Determines if the project uses static code analysis.

0

Vulnerabilities

Determines if the project has open, known unfixed vulnerabilities.

Score

1.7

/10

Last Scanned on 2024-11-18

The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.

Learn More