Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge changes upstream? #38

Closed
josephearl opened this issue Apr 10, 2017 · 1 comment
Closed

Merge changes upstream? #38

josephearl opened this issue Apr 10, 2017 · 1 comment

Comments

@josephearl
Copy link

josephearl commented Apr 10, 2017

I have a fork of gray-matter that splits out the core from the parsers, similar to the currently open PR. Parsers can define custom delimiters to enable auto-detection of that format.

Stringifying is supported for all languages. I've also removed the strict option in favor of just throwing errors.

I'd be happy to contribute the changes back in some form if you're interested. There are some changes to the interface in my fork - I opted for a .parse and .stringify to match JSON - but that should be simple enough to undo to make it feasible.

@jonschlinkert
Copy link
Owner

jonschlinkert commented Jun 17, 2017

@josephearl sorry for the very late reply. I'm interested in collaborating on this. I'll add you as a collab.

One thing I've mentioned in another issue somewhere that I think would be nice to do is to use an existing convention for the parsers (lol I like parsers).

I'm open to anything, but a couple examples are parsers and parser-cache (it's been long enough that I don't remember why I created both and what the main differentiation was going to be between the two).

In any case, the main goal would be to allow parsers to be registered the same way engines are with consolidate. I don't mind if you'd prefer to build the parsers into gray-matter, but it would still probably be nice to follow a convention (even the one you're using) so that implementors can use other parsers if they wish. This would also allow us to use these parsers for other non-front-matter purposes (we have "data loaders" in assemble that could use this).

does any of this sound ok? again I'm open to whatever. If you want me to add you to this lib, I'd be happy to (done. I just added you)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants