Modularization of library

[Nalinc]

There is a rising demand to move towards modularization of *marked * and separate different components in different files(grammar-rules, lexers, parsers and renderers). This though not have been mentioned explicitly, is evident from issues #743, #717, #704.

A properly modularized code would make maintenance easy and also allow addition of new grammar, implementation of custom parser, renderer and would address separation of concerns properly.

Like may be we can have an /src folder to fiddle with the code in development and use /lib for deliverable file.

[joshbruce]

@Nalinc: See #956

This idea is intriguing to me, primarily from the perspective of making it easier for the library to communicate what and how it works from an architectural perspective.

I don't know enough about Marked to do this work myself. What would you propose as a full folder structure given what's already here?

[Nalinc]

hey @joshbruce

I worked on marked a bit in past and even changed some of its functionalities based on my needs back then. One thing I found annoying was keeping track of things in the same file even if I was working on a different component. Here's what I did back then:

• I moved each of the primary components in a separate file in /src. This way I was left with core.js, grammar.js, lexer.js, parser.js and renderer.js in /src folder.
• Each of these components was written in IIFEs so they weren't messing with global scope.
• Finally, I had a grunt task that'd combine these components from /src and create a bundled file in /dist`

I found it easy because having independent components in different files, I could easily change/extend one component without worrying about others. The code became smaller, readable and more manageable too. I feel comfortable with marked and am open to make a PR on this.
Regarding #956, is there an exiting card for this or should I make one and move it to "under consideration"?

[joshbruce]

#420

#660

[joshbruce]

@Nalinc: Sorry it's taken a moment - I totally didn't see (or catch) your comments and questions at the bottom.

That architecture sounds about right to me; given what I've seen in the issues and PRs. Let me tag in a few of the other recently active community members to weigh in as well (@UziTech, @Feder1co5oave, @KostyaTretyak). There's not an existing card beyond this one; so, congrats on that. :)

Regarding submitting a PR, this is where I would like more feedback from the community. Our focus for the 0.4.0 milestone is to try and get functional issues taken care of. We have this card marked for the 0.5.0 milestone...but, if we can do it without much negative impact to cleaning up the other issues - I think it could actually help make things a bit more obvious on what's causing some of the other issues. I also know @UziTech is trying to make some improvements to all things testing, which will help the issue house cleaning and worthwhile for the 0.4.0 milestone as well.