how to refer old global variables in module package? I can’t even create a collection because Mongo is undefined. I don’t know how to import it.
import Mongo from 'mongo' this doesn’t work
update:
I have fixed this by
import {Mongo} from 'mongo'
and
api.use('mongo', 'server');
well, another question comes in: how to import Meteor and Accounts ?
Old global variables are still available in this new module package so you can just use it directly like how you did previously.
thanks, this is truth but strange. I don’t know if someday they will disappear, or there are some considerations for this.
So how we know what version of meteor we are using?
Can we continue to use the older versions if we have already started a project in it?
Well it’s well and good but it still doesn’t answer how we can import html files when using Blaze (on packages or if you create your own NPM package or Meteor package).
I think the JSX has its own import keyword and parsing that is different from CommonJS or from the ECMASCRIPT2015 specs. It’s clashing with each other.
Has anyone tried importing underscore from node_modules? It seems like instead of importing the correct underscore package from npm install, the default underscore package by Meteor is being imported.
The good news, however, is that npm installed Lodash is working fine and you can use it like how you did in normal node.js apps.
You can run cat .meteor/release and it will print out what version you’re on. You can always use older versions. Also using 1.3 without using the import keyword works fine on older apps. It will still use the older load order.
ok thanks. I have version 1.2.1
Yeah its seems jsx can only use the require syntax, not the es6 import sytnax (still learning react). Doesn’t seem like the comsos:browserify package will work with getting packages from the node_modules folder. I think its expecting a meteorhacks:npm configuration.
I wanted to use the browserify package because I was getting similar errors as ngochenbang above with process is not defined errors from react. My initial research seems to show that react is expecting a bundler like webpack or browserify to set these variables.
I’ll keep fiddling. I’m simply trying to get a base project with react and using react components from npm. I see the webpack option but just seems like overkill.
Just read this from the read-me:
Note: in the beta release of Meteor 1.3, Node modules are imported using the same entry point on both the client and the server (either the module identified by the main field of the package.json file, or index.js). For this reason, you should only import npm libraries on the client if you are sure they will work in a browser environment. We are considering implementing support for the browser field in package.json files, but we didn’t want to delay the beta release just for that
trying to update to meteor 1.3 and this is what i get for 2 h now:
and no restarting
does not help
I’m confused by this from the beginning of the ES2015 modules instructions:
"Nevertheless, the modules package is totally optional, and it will be up to you to add it to existing apps and/or packages.
For apps, this is as easy as meteor add modules, or (even better) meteor add ecmascript, since the ecmascript package implies the modules package."
With Meteor 1.2 the ecmascript package is included by default, so does that mean that existing meteor 1.2 apps get modules by default after upgrading to 1.3? That would appear to contradict the first sentence.
It’s just noting that ES5 CommonJS modules work without ecmascript. Modules are part of the spec, so ecmascript should definitely imply them. Not sure if MDG see any value in doing core packages with feature subsets, since it’s only there as a stopgap until the need for transpilation disappears. Maybe. If not, and if it’s important enough, you could just use and maintain your own package?
There is a distinction to be made between “lazy” loading, and dynamic loading (or code spliting), which is not mentioned in the documentation.
It would be easy to mistake lazy loading being talked about in the documentation for dynamic loading a la Webpack’s require.ensure and think that incremental loading exists now. As far as I know, you cannot do an import statement in the middle of your code.
I’m having the same problem. I think the process errors are related to not using webpack/browserify but import/export should still work within JSX.
.jsx file in meteor is compiled into plain Javascript through this jsx build plugin and it seems like this build plugin only transpiles some of the ES6 features so my guess is import/export is not one of those ES6 features.
You guys might try not using the packages react-runtime, and jsx and just stick with react-meteor-data to retain the mixin.
Then just use npm react. I’ll try it out today and see if it works.
@tjmonsi Maybe that’s a workaround for now . We should be able to use import/export though. I think @ngochenbang is right, maybe they just aren’t enabled in the transpiler. I submitted an issue here: https://github.com/meteor/meteor/issues/5795
My bad. I tried removing the jsx package but it didn’t work. The jsx files were not transpiled to js even when using just the ecmascript from Meteor 1.3
Has anyone got this set up with their React project and noticed faster page refresh times?