I think filing an issue is best. Keeping track of bugs in a forum thread is a nightmare once many people start posting about different stuff.
Yea I know, I just meant that the post kind of makes it sounds like we’re supposed to post in the thread on github which I’m sure is not the intention like you just said.
1 Like
Yes, by “application module” I just mean a module that’s part of an app rather than part of a package. In 1.3.3, modules in Meteor packages still use the Babel CommonJS module compiler, just like Meteor 1.3-1.3.2.4, because packages published with Meteor 1.3.3 need to continue working with older versions of Meteor, and the new modules compiler has some runtime dependencies that aren’t in older (pre-1.3.3) versions of the module system. Once most developers are using Meteor 1.3.3 or later, we can consider enabling the new compiler for package modules as well as application modules.
1 Like
If that FlowRouter.route code is in an app, then there may be a bug. If it’s in a package, then import statements are still restricted to the top level, and you’ll have to use require there.
It’s in an app. I’ll file an issue over the weekend.
2 Likes
We’re not able to use other Babel plugins in Meteor packages? That’s a SERIOUS problem and oversight IMO.
I have 150+ packages in my app and I’m using extra Babel transforms (namely transform-class-properties) in all of them. If I’m not able to use my Babel transforms in packages it’s going to be a BIG problem for me and essentially makes 1.3.3 unusable for me which also means 1.4 is going to be unusable and that’s a big problem.
Can it not be optionally enabled in packages? I don’t publish any of my packages, they are used internally since I set them up when they were the only way to manage load order.
It would cost me a couple weeks of time to migrate everything over to be an application and I do not have time for that.
If you’re already achieving this somehow, can’t you just keep doing what you were doing? I don’t think we’re talking about any breaking changes here.
How do I then update to Meteor 1.4 and continue to take advantage of the continued updates and improvements in the Meteor ecosystem?
I’m using gadicc:ecmascript-hot right now but when the next release comes out it will no longer support .babelrc because that is supposed to be supported in core as of 1.3.3. If you’re leaving out Meteor packages it really isn’t fully supported at all.
You can just keep using the same version of ecmascript-hot you were using before, and upgrade to Meteor 1.4, no?
It’s going to continue to be improved along with the rest of the ecosystem. It isn’t eminently stable right now as is going to be updated alongside Meteor 1.3.3 because it was expected to have full babelrc support.
It’s also currently tied to a specific version of Meteor due to the dependencies on parts of babel-compiler and other build dependencies.
I’m having trouble using my .babelrc file at all.
=> Modified -- restarting.
=> Errors prevented startup:
While processing files with ecmascript (for target web.browser):
module.js:338:15: Cannot find module 'transform-class-properties'
at Function.Module._resolveFilename (module.js:338:15)
at InputFile.resolve (/tools/isobuild/compiler-plugin.js:355:14)
at InputFile.<anonymous> (/tools/isobuild/compiler-plugin.js:359:25)
at InputFile.require
(/Users/clayne/.meteor/packages/meteor-tool/.1.3.3-beta.1.ecodx3++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/tools/isobuild/compiler-plugin.js:364:23)
at req (packages/babel-compiler/babel-compiler.js:215:1)
at packages/babel-compiler/babel-compiler.js:232:1
at Array.forEach (native)
at infer (packages/babel-compiler/babel-compiler.js:230:1)
at BabelCompiler.BCp._inferHelper (packages/babel-compiler/babel-compiler.js:251:1)
at BabelCompiler.BCp._inferFromBabelRc (packages/babel-compiler/babel-compiler.js:163:1)
at BabelCompiler.BCp.inferExtraBabelOptions (packages/babel-compiler/babel-compiler.js:150:1)
at packages/babel-compiler/babel-compiler.js:92:1
at Array.forEach (native)
at BabelCompiler.BCp.processFilesForTarget (packages/babel-compiler/babel-compiler.js:40:1)
I have transform-class-properties in my devDependencies.
The .babelrc feature works everywhere. I was clarifying the language I used to describe the changes to import statements. What’s new is that application code uses a different (much better) modules transform, whereas package code compiles modules the same as 1.3.2.4.
1 Like
OK that’s great to hear! I’m still have the problem I listed above with 1.3.3-beta.1. Any idea why Meteor isn’t seeing my transform-class-properties plugin?
Please do file an issue with a reproduction 
I’m having a ton of issues trying to update to release 1.3.3-beta.1 on Windows due to the bcrypt upgrade. I’ve tried a lot of different work arounds in both my Windows 10 and Windows 8.1 environments and I just can’t get up an running. Is anyone else having this problem with the beta?
I am just not sure, if it’s a good idea to make import statements dynamic since it’s not really what ES6/7 is doing? I can already see threads bumping up “why it’s working here but not there”. Maybe those should be require statements in the first place. But I can be completely wrong…
3 Likes
New release: 1.3.3-beta.2
To update to the latest beta release of Meteor 1.3.3, run
meteor update --release 1.3.3-beta.2
in an application directory.
2 Likes
I’m dealing with the same issues @clayne is, seeking to get babel’s transform-class-properties plugin working. Sample code for the excellent material-ui component library requires it for actions, e.g.:
handleClose = () => this.setState({open: false});
I hope version 1.3.3x/1.4 will have an easy way to include transform-class-properties.
Did you wipe the node_modules dir and reinstall? that with babel-plugin-transform-class-properties worked for me.
I’ll try it now. What version of Meteor are you running? Are you using .babelrc to load the plugin-- and if so does your .babelrc look like this?
{
"presets": ["es2015", "stage-0", "react"],
"plugins": ["react-require", "babel-root-slash-import", "transform-class-properties"]
}