Uncaught TypeError: fs.readFileSync is not a function

[kachkaev]

​I'm trying to use meteor npm installreact-map-gl and end up with this fatal error in a browser:

svg.react.js:61 Uncaught TypeError: fs.readFileSync is not a function

My guess is that the issue is somehow related to the way meteor mocks nodes's fs methods. I've added meteor-node-stubs to my local node_modules, but this did not help.

I understand that using fs.readFileSync on a client is odd, but assume that there is a reason for referencing this method. It does not seem to cause problems in apps that are built not with meteor, so I guess we should not move the issue upstream.

Trying everything on Meteor 1.4-beta.9. Any ideas on a temporal workaround?

[kachkaev]

Just found a relevant discussion on Meteor forums, but the solution is still unknown.

UPD: One more linked discussion thread

[kachkaev]

It appears that the issue I'm facing is sourcing from this file: mapbox-gl-shaders/index.js. It is expected to be processed by webpack and turned into a single file where occurances of fs.readFileSync are replaced with the actual content of the files.

Meteor does not seem to be able to process such a thing. Any ways to overcome the problem with the current build system?

I could have tried to just use a dist version of mapbox-gl-js, but only if there was no react wrapper. Uber's react-map-gl sets mapbox-gl-jsas a dependency and imports various sub-dependencies in its code using import/require.

[kachkaev]

Another interesting thing is seeing svg.react.js in the exception log. The error does not belong there at all. Something must be wrong with how meteor makes source maps in 1.4-beta.9

[Nexus7]

I think we are also seeing this similar error with fs using another npm package... on the browser console we see function not defined errors. I think the meteor-node-stubs just gives you an empty object for 'fs' so I think that is why it happens. Previously we used meteorhacks:npm to install the package and cosmos:browserify to use the package on the client side.

However as we are currently trying to migrate to Meteor 1.3/1.4 we were hoping to ditch both these packages and just use the native npm... From the Meteor guide it seems that we should just be able to do an import on both client and server without problems but obviously in our previous method some more magic was being conducted which has now dropped out of our build process...

[super-iterator]

@kachkaev any luck to get fs.readFileSync working on the client side? facing the same thing here!

[kachkaev]

I ended up switching to webpack where I was able to configure a transform when loading mapbox js files. fs.readFileSync is now executed during build so the browser gets the result of this function, not the function call itself.

Maybe this thread of a few neighbouring ones can help you: mapbox/mapbox-gl-js#1649

[abernix]

fs.readFileSync will never truly work on the client as it's Node functionality and the browser is not Node.

Closing for a similar reason as #7567, but mostly because the discussion in #6890 is the closest thing to a more generic, actual solution for this (rather than having individual issues about NPM modules that don't work).

And from #7567:

meteor-node-stubs is available to try to solve this, however you can install whatever functions you'd like to mock Node functions and have them behave as you wish. Additional conversation can be found in these issues:

• [1.3-rc.8] possible issue with third-party lib on client, cannot find module 'fs' #6578 (comment)
• Object form of browser in package.json not supported #6890 (comment) (open, and ultimately a solution)