Marked: Setting options interferes with other "require"-calls to marked.

[nknapp]

In my NodeJS-project, marked is used by the main program and by a dependency.
When the main-program calls setOptions, the same options are also applied to the instance that is used by the dependency, because both instances are the same object.

I think, a better way to apply default options, would be like the request-package is doing it.
They create a new instance that is configured with the default options, so the original instance is untouched.

What I will try now, is to clear the cache before and after requiring marked, but that seems like a weak workaround.

[Feder1co5oave]

idk if this is viable for you, but you could avoid setting options with setOptions and instead pass options to marked as second argument.

I do agree with you that setOptions should return a new marked instance instead! But that is an API change.

[joshbruce]

Again, I'm not too familiar with working directly with Marked; so, pardon the ignorance. Also, this sounds like the problem with Singletons (especially if they're configurable).

var marked1 = Marked().setOptions();
var marked2 = Marked().setOptions();

Is that not the way things work? Sounds like each package would want to create the instance, at which point you would access via something like:

var package = Package();

package.marked.setOptions();

In either case I'm not sure how much this is on Marked to correct. Will flag it for the 0.6.0 milestone; closing.

[UziTech]

A work around is to use

const marked = require('marked');
marked.setOptions(marked.getDefaults());

to make sure that defaults are set to the initial defaults.

[Andarist]

The proposed workaround can break those other marked "instances" which is also not good overall.

[UziTech]

True. You could also send options as a second parameter to marked to override the defaults just for that call.

const marked = require('marked');
marked(markdown, marked.getDefaults());