Marked: DEPENDENCIES.md

[joshbruce]

We are starting to add a few more dev dependencies to try and improve things. Was thinking about it and it might be worthwhile to create a dependencies list file. I tend to shy away from dependencies for a few reasons:

1. What if the dependency falls into disrepear or something better comes along?
2. The YAGNI principle - do we actually need what the library gives us?
3. Another principle I will call the community principle: If you create or acquire it, you help maintain it. (Less dependencies, less things I'm actively or passively helping to maintain.)

Initial thoughts on the layout of a dependency document

What problem is being solved

• The dependency being used

Fallbacks/Alternatives

• List of
• alternatives
• that would
• help resolve
• the same or similar problem

[Feder1co5oave]

I'm with you on this, I don't like pointless dependencies either. All of them should be motivated with valid reasons. And we still want to be lightweight.
The good thing is that dev dependencies are not required for marked to _work_ as it should, they only aid in developing it. So, in this sense, we're still lightweight, marked has no dependecies.

[joshbruce]

Agreed. I'm also thinking if we can find things that follow a "plug-in" architecture (thinking Bob Martin here). We have the test capability provided by @chjj and @UziTech, for example, and the things we add (like the differ) should be able to plug into that...that way we could bail on it, but still have the test capability...just to make sure we're being explicit there. ;)

[UziTech]

I don't know if we need to have a file to list the dependencies. Anyone can look in the package.json file for a list of dependencies.

For all of my projects I use https://david-dm.org/ to add a badge to my readme which will turn red if any of our dependencies are found to be insecure, and yellow not up to date

Here are the ones for this repo:

[joshbruce]

@UziTech: Interesting. Thanks, might be worth having. What about tracking why we use them and fallbacks shoudl they turn into what Marked had become?

That was one of things I noticed a lot going through the issues. Folks didn't really know what to use other than Marked. Some of this is also my own baggage since the proliferation of packages in general - developers not fully understanding what, if anything, the dependencies were are giving them...a crutch, so to speak (again, my baggage on the subject).

[joshbruce]

Closing as not a lot of traction. Maybe when the dependencies stabilize a bit more.