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

request: make gray-matter natively, backwards-compatible with older browsers #49

Closed
tech4him1 opened this issue Sep 14, 2017 · 9 comments

Comments

@tech4him1
Copy link

gray-matter uses features of Node that are not supported in all browsers (e.g. let, const, fs module). This is a big downside, as the entire gray-matter module must be run through something like Babel to work. Even then, it would fail while importing the fs module. Would you consider supporting this, maybe with a pre-built version of gray-matter that can be used on the web?

@jonschlinkert jonschlinkert changed the title gray-matter cannot be used outside of Node.JS request: make gray-matter natively, backwards-compatible with older browsers Sep 14, 2017
@jonschlinkert
Copy link
Owner

Hi, gray-matter is after all a node.js module. I might consider dropping let, const etc. in favor of var, I typically do that anyway. But given that it's a big edge case to use this library in the browser without some kind of pre-processing with webpack or browserify, and there are solutions for importing fs using plugins with those libraries, I'm struggling to see how it makes sense to drop fs from this library for this specific edge case.

What is the reason for using gray-matter in the browser?

@tech4him1
Copy link
Author

tech4him1 commented Sep 14, 2017

@jonschlinkert The actual project that we are using it for is Netlify CMS. You had suggested that we switch back to gray-matter after the improvments that you made in v3.0.0. Since it is all in-browser, just using APIs to load the files, it needs to be able to parse the front-matter in-browser as well. There are solutions for working around those limitations, I was mostly wondering if you were willing to keep this module browser-compatible, or whether you didn't really care about browser-compatibility at all (since it is a node module).

@tech4him1
Copy link
Author

You also make a good point about the fs module, if WebPack or Browserify is not used, all of the require calls would fail anyway.

@jonschlinkert
Copy link
Owner

I was mostly wondering if you were willing to keep this module browser-compatible, or whether you didn't really care about browser-compatibility at all (since it is a node module).

I care if it's a use case consistent with why we created the module, which was to support static site generators. I think your use case is consistent with that. I can start by reverting to var then we can go from there. sound ok?

@tech4him1
Copy link
Author

@jonschlinkert That sounds good. Just as long as the module in general stays browser-compatible and doesn't use any Node-specific things, that will be awesome!

@tech4him1
Copy link
Author

tech4him1 commented Sep 14, 2017

@jonschlinkert Another way that would work for us if you don't want to change the sources would be to have a re-packaged version for browsers that was run through Babel or something like that and left out the Node functions like matter.read/fs.

@jonschlinkert
Copy link
Owner

k fixed and published as 3.0.4. I'll create a new issue to discuss fs.

@tech4him1
Copy link
Author

Template strings are a new browser feature as well.

@jonschlinkert
Copy link
Owner

Template strings are a new browser feature as well.

good catch

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