-
Notifications
You must be signed in to change notification settings - Fork 24.7k
[Packager] Requiring json file failed #773
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
Comments
I've had similar issues. I think it might have to be w/ the fact that the CommonJS implementation is not a full implementation for this framework. |
This would be nice to support. Internally, we would just rename to cc @amasad |
This landed internally, should land here next sync. |
would this be the same issue as trying todo require('./package') resulting in 'unknown module' ? |
@alexaivars - if when you do that you are trying to require package.json then yup, same thing |
awesome, hope the next sync lands soon. |
I didn't know that |
@amasad I can confirm that this is true and that it's a quite common practice to require package.json in this fashion. I however first noticed this since react-native chocked when I required cheerio. |
Any news on this front? I found that most scrapers seem to require some package that does this doe there is not much to be gained by switching to another library. #231 says the JSON requiring bug was fixed, yet I'm still getting errors with 0.4.4 |
@paulgessinger Yeah, |
Fixed this internally, should land next sync. |
+1 |
…d, fix bugs etc) Summary: @public Fixes facebook#773, facebook#1055 The resolver was getting a bit unwieldy because a lot has changed since the initial writing (porting node-haste). This also splits up a large complex file into the following: * Makes use of classes: Module, AssetModule, Package, and AssetModule_DEPRECATED (`image!` modules) * DependencyGraph is lazy for everything that isn't haste modules and packages (need to read ahead of time) * Lazy makes it fast, easier to reason about, and easier to add new loaders * Has a centralized filesystem wrapper: fast-fs (ffs) * ffs is async and lazy for any read operation and sync for directory/file lookup which makes it fast * we can easily drop in different adapters for ffs to be able to build up the tree: watchman, git ls-files, etc * use es6 for classes and easier to read promise-based code Follow up diffs will include: * Using new types (Module, AssetModule etc) in the rest of the codebase (currently we convert to plain object which is a bit of a hack) * using watchman to build up the fs * some caching at the object creation level (we are recreating Modules and Packages many times, we can cache them) * A plugin system for loaders (e.g. @tadeuzagallo wants to add a native module loader) Test Plan: * ./runJestTests.sh react-packager * ./runJestTests.sh PackagerIntegration * Export open source and run the e2e test * reset cache * ./fbrnios.sh run and click around
I have one config.json in the app directory, and also a List.js.
In List.js, it tries to load config.json using
require
(which is common in node.js). But it failed.The text was updated successfully, but these errors were encountered: