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

V3 Punchlist #37

Open
1 of 9 tasks
jxson opened this issue Feb 13, 2016 · 5 comments
Open
1 of 9 tasks

V3 Punchlist #37

jxson opened this issue Feb 13, 2016 · 5 comments

Comments

@jxson
Copy link
Owner

jxson commented Feb 13, 2016

Here is a meta list of items for v3, in no particular order. This is mostly a brain dump and some notes from chatting with @axdg

  • Refactor the tests so they work in browser and add a SauceLabs badge Browser tests #6
  • Add benchmarks and add results to the README
  • Refactor internal implementation to resemble axdg/dsfm (Faster Regex usage, etc.)
  • Steaming support Streaming Support #24
  • Custom parser support (maybe the only built it one is JSON, everything else should use this API to keep down dependency sizes?) Custom separator and parser. #22
  • Deprecate v2
  • Clean up README
    • Add information about the size of the module (including dependencies) for browser users
    • Add better information for collaborators and maintainers about development workflow (testing, code reviews, publishing, etc.)
@axdg
Copy link
Collaborator

axdg commented Feb 13, 2016

Yep, this all looks good.

Just a few notes:

  • Regarding Reverse generating a file #26; @qimingweng I'm not sure that 'stringifying' a 'contents' object is necessarily something that needs to be done by this module. It's something that is trivial to do (just concatenating stringified attributes and the body of the document). Creating a stream that does this is also pretty trivial. While it's not a bad feature to have in the module, it doesn't really fit in with the idea of custom parsers, where the user supplies their own load function for the front-matter. It would mean that the user would also need to supply a function to 'dump' or stringify the front-matter.
  • Having only YAML and JSON parsers built in seems logical to me. YAML if the default format for front-matter, JSON is probably the next most common (and doesn't require another dependancy).
  • Browser support should not come through a seperate version - it's reasonable to expect that the user would be using browserify etc. But it's fine to test in browsers.

@qimingweng
Copy link

@axdg yeah I can see your point for #26, so maybe it makes more sense as a separate npm module? I do think it would be convenient as a tool for novices to come and pick up both front-matter and its reverse.

We can maybe even write a smart YAML re-writer that updates keys in the places they already are and keeps comments as much as possible. But that may be a separate exercise that really does deserve another npm module.

@jxson
Copy link
Owner Author

jxson commented Mar 2, 2016

@axdg how is the dsfm merge coming along? Is there anything I can do to help?

@axdg
Copy link
Collaborator

axdg commented Mar 3, 2016

Hey @jxson, apologies, I've had less time to deal with this than I'd expected.

I've found one minor bug in dsfm (it's not trimming carriage returns (\r) where DOS newlines are present) that I'm trying to figure out the fastest method to overcome. Otherwise it's just a matter of changing the names of a few variables and merging both test sets - I will have the v3 branch up and running over the weekend.

@jxson
Copy link
Owner Author

jxson commented Mar 3, 2016

@axdg no sweat! Just thought I would check in.

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

3 participants