Error using built-in node module dependencies using import syntax [Meteor-1.3-beta.3]
#5963
Comments
emgee3
changed the title
import syntax [Meteor-1.3-beta.3]import syntax [Meteor-1.3-beta.3]
|
I receive a similar error with superagent. import request from 'superagent' I am using 1.3 beta 3 |
|
Having the same problem. When using "import" or commonjs "require" to import any module, meteor cannot load the built-in node modules imported inside that module and gives multiple error messages "could not resolve module xxx" |
|
This is an error that I added in the most recent beta release, but it appears to be (way!) too strict. Sorry about that. Two options:
|
|
After thinking about this some more, I'm afraid the first option is the only option. Any code that runs on more than one platform is likely to contain platform-specific parts (think |
|
Can import statements not only be at the top level, so there is no case where import is inside if(Meteor.isClient)? |
|
@sanjo import bar from 'bar' // just fine
if (true) {
import foo from 'foo' // error!
} |
|
@sanjo @trusktr With the current Meteor |
|
Even if we forbid nested |
|
@trusktr built-in modules are those special modules in Node for which |
|
Yeah, having platform specific imports is really necessary if you want to import a module in a isometric code module. Maybe another way to achieve that would be that Meteor picks the right entry point in the module for the platform. So if you import myModule from 'my-module', on the client side it would require myModule/client. And on the server side it would require myModule/server. Both, the client and server folder have an entry point file that exports everything of the module for the platform. The same thing could be also achieved on a file granularity with file extensions like .client.js and .server.js. |
|
Beta 4 fixed my issue, thanks! I've left the issue open because of the ongoing conversation, but feel free to close. |
|
@emgee3 Thanks for confirming. Happy for discussion to continue! |
|
I still cannot import superagent. I am on beta 4. Meteor does not crash like beta 3, but I get the error: Cannot find module 'tty' at runtime in my console. Which is an internal dependency of superagent. I also noticed that the first post the error started with: While building for os.osx.x86_64: The modules I am having trouble with are modules that are built into with Node itself. |
|
@readydestroy browser console or server console? |
|
Browser console. Running code from my client folder. |
|
Ah, If you really need those modules on the client, you can do something similar to what browserify does: npm install tty-browserify
echo 'module.exports = require("tty-browserify");' >> node_modules/tty.jsThis installs a stub implementation of the Node |
|
Thanks! That make sense. I am used to having browserify in my workflow and now I don't with meteor. Any tips to streamline that process? |
|
After thinking about it more, you probably want to use the real implementation on the server, so a better version of Automatically providing stub implementations for built-in modules is definitely something I would consider, but it probably won't happen until after 1.3. In the meantime, you should feel free to bulk-install any/all browserify stub packages. They won't be included in your app bundle unless you actually use them, so you don't have to worry about figuring out exactly which ones are used. |
The good thing is even if native implementations don't support this at first, it could always be added later, which would be backwards compatible. So, the debate |
|
@benjamn We're running into this issue with superagent as well. I believe the convention modules are adopting is use of the "browser" field in the package.json file. That's what superagent does, as briefly discussed here: ladjs/superagent#822 Any chance of supporting this property? I believe this might also take care of #5970. Edit: just realized you linked to browserify's support of the "browser" field in the issue linked above. I believe webpack supports this as well. Some discussion on the topic here: |
|
Alternatively you could import that file directly. /#!/JoePea
|
|
@emgee3 , ERROR in ./node_modules/aws-sign2/index.js |
When importing npm packages that use built-in node module dependencies, such as the Twilio module, Meteor errors when trying to load built-in node modules.
When using the twilio module from inside a package, I can use
Npm.require('twilio')which will correctly import the built-in modules, but in 1.3, where one usesimport twilio from 'twilio'this is not the case.The text was updated successfully, but these errors were encountered: