Module not found: Error: Cannot resolve module 'fs'

[pjm17971]

Hi, thanks for this library, but I'm trying to integrate this in a timeseries library of ours so that users can serialize in avro. This works fine on node, but when I bring this library into another library used in the browser (timeseries visualization), I get this webpack error:

Error in ./~/avsc/lib/files.js
Module not found: Error: Cannot resolve module 'fs' ...

I tried to import like so:

import avro from "avsc/etc/browser/avsc-protocols";

but that didn't help. Any ideas how to deal with this without having downstream libraries having to mock fs etc. ?

[mtth]

I haven't spent much time on webpack support yet, I can try to look into it. In the meantime - are you using any RPC-specific functionality? If not, you might be able to fix it by requiring 'avsc/etc/browser/avsc-types'.

[Tamriel]

That is a common error which I solved like this: josephsavona/valuable#9 (comment)

[pjm17971]

@mtth Thanks for the response. The use of the library is pretty simple right now, just using a schema to build a buffer and decode a buffer. Other stuff would be cool, but it's needed at this point. In my simple test app this morning, the import 'avsc/etc/browser/avsc-types' approach seems to work, so that's promising. I'll try to put the whole library back together today and see if it works downstream. Will report back.

It might be nice to have a good story re: webpack on the front page README, because any kind of facebook type dev stack in probably going to use it, at a minimum. Another option might be to build a avsc-browser npm package? On the other hand, if it doesn't generally cause a problem, or finds minimal use on the browser, I don't know if that would be worth it. Something to consider though.

@Tamriel Yeah, that's true, but I'd rather not require downstream library users to have to do this as the actual situation is: user-code depends on visualization-library depends on timeseries-library--with-avro-support depends on avsc. Another concern is they may not control their webpack configs either, e.g. create-react-app.

[ Edit: though it does seem that at some point mocking fs and friends (if that's the right way to describe what webpack is doing) was added to create-react-app's config. But even still importing the top level entry point of avsc causes a this.buf.utf8Write is not a function runtime error. ]

[mtth]

After thinking about it for a while, here's a plan that should work:

• In the short term, rather than having shims in etc/browser/ (which mostly only work for browserify), I'll add the appropriate logic in the main source directory. I was hesitant at first since it "pollutes" the rest of the code, but it seems the simplest way to support other browser environments.
• Longer term, I'll refactor the overall avsc module into separate smaller packages, similar to the browser distributions: one for serialization, one for RPC, and another for files. This will allow reducing bundle sizes.

The first change should go live with 5.0 in a couple weeks.

[pjm17971]

That sounds perfect.

[mtth]

Just released 5.0.0. I tested that a standard Webpack build with require('avsc') works (in particular fixing the "this.buf.utf8Write is not a function" error). Feel free to reopen if you notice any new issues.