Thank you! This was valuable information! I really don’t want to hard separate client code anymore.
Where is this limitation coming from in the build process? I want to add a ticket to meteors 1.3 track
PS: I assume you simply put components and screens into a client folder
I added a bug ticket. We need to get away from the client/server split up.
Thanks, @dinos! I never really tracked it down in the code, just noticed the behaviour.
Yes, I was too lazy to adjust the server links too, so just copied all the folders into the client folder and adjusted the client/style entry files. Obviously if you wanted to go this route you’d need to restructure properly, but for testing purposes this was good for me :>
Yeah, since this todo is an example of a … not very trivial large app… with a team… I currently investigate if its enough to have components and screens under a clients/ folder. But as beniot, would be grade if you could chip in on the issue above at metoer and stress, that the current watcher behavior feels like a hack.
Has anyone had good luck enabling decorators using this?
I tried by adding the transform-decorators plugin but it always complains about adding the decorator plugin before the class plugin!
While processing files with gadicc:ecmascript-hot (for target web.browser):
framework/client/components/baseComponent.jsx:10:4: /framework/client/components/baseComponent.jsx: Method has decorators, put the decorator plugin before the classes one.
New release: gadicc:ecmascript-hot@0.0.13-rc.10
Works with Meteor 1.3 rc.4 - rc.10.
No longer auto-populate babelrc presets with meteor, to allow other
plugins to be loaded before those in the preset. If you don’t already
have a .babelrc, one will be created for you. If you do, ensure you
have { "presets": "meteor" }. Also,
npm install --save-dev babel-preset-meteor.
@dortega, this release should solve your issue, let me know. I had to use transform-decorators-legacy and I guess you saw the notes about this.
@dinos, sure, will chime in after 1.3 final is released, which seems like any day now. This would be great for all of us 
Everything is working now, here is the .babelrc I used for decorators
{
"presets": [
"decorators-legacy",
"meteor"
],
"plugins": [
"transform-decorators-legacy",
"jsx-control-statements"
],
"env": {
"development": {
"plugins": [
[
"react-transform",
{
"transforms": [
{
"transform": "react-transform-hmr",
"imports": [
"react"
],
"locals": [
"module"
]
},
{
"transform": "react-transform-catch-errors",
"imports": [
"react",
"redbox-react"
]
}
]
}
]
]
}
}
}Great stuff, happy to hear it!
New release: gadicc:ecmascript-hot@0.0.14-rc.12
Works with Meteor 1.3 rc.4 - rc.13 and 1.3 (final)
Fixed a bunch of issues that broke production and bundling:
Don’t transform stateless components, don’t connect to Mongo,
don’t replace modules-runtime, don’t block HCPs, and lastly,
use NODE_ENV as part of the babel cache hash.
Use JSON5 for parsing .babelrc, just like babel does.
This allows for comments, etc.
Trying this on both rc.12 as latest 1.3 release, but I get a connection error:
[gadicc:hot] Failed to connect to your Mongo database on "mongodb://localhost:3001/meteor"
What OS are you on? How are you launching Meteor? If you run Meteor without this package, and type meteor mongo --url in your project directory from another terminal, what does it say?
OSX 10.11.4, launching with just meteor. It’s a bare Mantra app, nothing in it.
Two scenario’s:
meteor without gadicc:ecmascript-hot@0.0.14-rc.12 and run meteor mongo --url in another terminal. Result: mongodb://127.0.0.1:3001/meteor.meteor with gadicc:ecmascript-hot@0.0.14-rc.12. It won’t start because of that error. Then run meteor mongo --url in the same terminal. Result: mongodb://127.0.0.1:3001/meteor.Mmm. And was there any more detailed info below that error line from before?
Does starting Meteor like this:
MONGO_URL="mongodb://127.0.0.1:3001/meteor" meteor
work any better? Maybe there’s a reason why Meteor chose to use 127.0.0.1 instead of localhost. I admit I don’t really know OSX at all.
I found the same problem using a cloud9 instance.
meteor mongo --url
mongodb://127.0.0.1:8081/meteor
(Noting that Cloud9 uses 8080 for the http port, specified environment variable METEOR_PORT=8080, the mongo port must be just one higher.)
This is the full trace:
[gadicc:hot] Failed to connect to your Mongo database on "mongodb://localhost:3001/meteor". Try MONGO_URL environment variable or "-p PORT" when running Meteor.
/Users/Sander/.meteor/packages/gadicc_ecmascript-hot/.0.0.14-rc.12.qnvn1m++os+web.browser+web.cordova/plugin.compile-ecmascript-hot.os/npm/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/mongodb/lib/server.js:236
process.nextTick(function() { throw err; })
^
Error: MongoError: getaddrinfo ENOTFOUND
at packages/gadicc_babel-compiler-hot.js:155:11
at /Users/Sander/.meteor/packages/gadicc_ecmascript-hot/.0.0.14-rc.12.qnvn1m++os+web.browser+web.cordova/plugin.compile-ecmascript-hot.os/npm/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/mongodb/lib/mongo_client.js:276:20
at /Users/Sander/.meteor/packages/gadicc_ecmascript-hot/.0.0.14-rc.12.qnvn1m++os+web.browser+web.cordova/plugin.compile-ecmascript-hot.os/npm/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/mongodb/lib/db.js:224:14
at [object Object].<anonymous> (/Users/Sander/.meteor/packages/gadicc_ecmascript-hot/.0.0.14-rc.12.qnvn1m++os+web.browser+web.cordova/plugin.compile-ecmascript-hot.os/npm/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/mongodb/lib/server.js:234:9)
at [object Object].g (events.js:180:16)
at [object Object].emit (events.js:98:17)
at [object Object].<anonymous> (/Users/Sander/.meteor/packages/gadicc_ecmascript-hot/.0.0.14-rc.12.qnvn1m++os+web.browser+web.cordova/plugin.compile-ecmascript-hot.os/npm/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/mongodb/node_modules/mongodb-core/lib/topologies/server.js:269:68)
at [object Object].g (events.js:180:16)
at [object Object].emit (events.js:98:17)
at [object Object].<anonymous> (/Users/Sander/.meteor/packages/gadicc_ecmascript-hot/.0.0.14-rc.12.qnvn1m++os+web.browser+web.cordova/plugin.compile-ecmascript-hot.os/npm/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/mongodb/node_modules/mongodb-core/lib/connection/pool.js:81:12)
at [object Object].g (events.js:180:16)
at [object Object].emit (events.js:98:17)
at Socket.<anonymous> (/Users/Sander/.meteor/packages/gadicc_ecmascript-hot/.0.0.14-rc.12.qnvn1m++os+web.browser+web.cordova/plugin.compile-ecmascript-hot.os/npm/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/meteor/gadicc_babel-compiler-hot/node_modules/mongodb/node_modules/mongodb-core/lib/connection/connection.js:124:49)
at Socket.g (events.js:180:16)
at Socket.emit (events.js:95:17)
at net.js:834:16
at process._tickCallback (node.js:458:13)
Yes, that worked indeed. But I wonder why?
Usually systems resolve ‘127.0.0.1’, via an entry in the hosts file (apparently in /private/etc/hosts on OSX), i.e. if you ping localhost it should resolve to 127.0.0.1. I guess this isn’t guaranteed on OSX, so I’ll just use 127.0.0.1 directly in the next release (or I guess, be smarter about checking what Meteor is using).
Thanks for the heads up, will address this in next release.
No, this is an error on my side… I just realized I renamed /etc/hosts for a completely different reason. Things work again, no need for you to change it.
Although I don’t know why it didn’t work for @boormat.
Haha, ok, thanks. I’m still going to go ahead, since this should still work in any situation that Meteor was working in.
@boormat’s problem is slightly different, I never thought to check the METEOR_PORT environment variable until now.
New release: gadicc:ecmascript-hot@1.3.0-1
Works with Meteor 1.3 (final) and rc.4+
Speed increase by re-using inputfile.getSourceHash() instead of hashing
twice.
Correctly hash on BABEL_ENV too (if it exists).
Use 127.0.0.1 instead of localhost for mongo url.
Use Meteor’s METEOR-PORT file to figure out the mongo port.
I’m attempting to use this package right now with the latest version of the Meteor 1.3 RC, and I’m getting the following error in browser console when loading up my app.
Uncaught TypeError: modulesRuntime.meteorInstall._expose is not a function
As for packages I have installed, I’m using yours as a replacement for ecmascript, and I’m just using the .babelrc that’s generated by your package, I didn’t have one pre-written.
I’m using react, redux, react-redux, and react-router, as far as NPM stuff goes, but I wouldn’t think that would have anything to do with this, I feel like I might be doing something wrong, but not sure what. If you have any questions to ask as far as diagnostics go, let me know and I’ll respond ASAP. I’d like to get this working for sure.
All of my components are authored using the React.createClass method, not by extending their class, or whatever that method is.
Thanks in advance!
Ok, first hunch, does ctrl-shift-R fix this for you? (If it does I need to fix something)