I was also looking for a tutorial of sorts…something to show how we tie ES2015 with Meteor and I found this. Gives a good overview.
This also helps if you encounter “This project is at the latest release which is compatible with your current package constraints.” when trying to update from rc <= 10 to rc >= 11, and removing all packages from .meteor/packages didn’t help.
1 Like
Fix for our app was actually to move away from npm-container and use Meteor’s built-in NPM support instead.
How to:
rm -rf packages/npm-container
meteor remove npm-container meteorhacks:npm
npm install # in Meteor app directory
Then in any .js replace all occurrences of Meteor.npmRequire with Npm.require.
Thanks. I was having the same message and this solution allowed me to upgrade.
Trying the release RC-7, when I do whatever modification in a scss file, the Meteor crash with the following message: “Scss compiler error: invalid top-level expression”. I’m using the fourseven:scss package and following the tutorial: https://medium.com/@SamCorcos/building-campaignhawk-with-meteor-and-react-part-2-d4551708dcde
When restarting the server, everything works.
I’m seeing an unreliable build with 1.2 rc12. I did a meteor update that updated only one package (sergeyt:typeahead, not that it’s likely to be relevant). Following this, I’ve got all sorts of corrupted objects, as though my code wasn’t correctly built.
Just rolling back the .meteor/versions to before the last update doesn’t fix it.
But rolling back everything to one commit earlier does. Once that older commit has built I can then checkout the commit right before the problematic meteor update and everything’s fine again. Checkout the updated .versions and it’s bad again.
So it seems the build is being result is being determined by something other than the source.
Is this normal and expected behavior? If so, what’s the magic incantation to clean before building? If not, what might I be missing (or not have done correctly in the move to 1.2) that could cause this?
Update:
I found this to be caused by the build resurrecting old versions from its cache. By clearing the cache I got temporary relief. However, after a few more changes it’s back to recycling old versions inappropriately. Also, it’s not limited to rc12; I’ve gone back to rc7 and it’s the same.
Any suggestions what might be causing this and how to cure it?
I was using grigio:babel in several packages before updating to 1.2-rc.12. I wasn’t in a hurry to remove it since it seemed to be working, but since I’m now stuck where I can’t make changes without getting build problems I thought I’d try removing grigio:babel and see if that helps anything. Removed it from all my packages, renamed all the files to .js and it all seems to build.
Unfortunately, it seems that just using the ecmascript package doesn’t let me use the new ES2015 Array.from or Array.fill the way I could with grigio:babel. I get an exception ‘fill is not a function’. If I work around that, I get all sorts of other problems cropping up.
Is there some other switch I need to throw to enable ES2015 features?
I’ve got .jsx files in my app that seem to be working ok but the .js files in my packages are not so happy.
[Edit]
I tested with a simple test app and same problem there, so it’s not specific to code in packages.
Sample offending code:
const a = new Array(4).fill(1);
give me:
Uncaught TypeError: (intermediate value).fill is not a functionI’m new to Meteor and I’d like to start a new (React-based) Meteor app.
Should I start my app with the 1.2 RC or should I use the 1.1 release?
What doese make more sense?
1 Like
Personally I would use it as long as your not going to launch before it’s released. Also be prepared for some packages to break if they have static assets… I had to fork one and add one line in the packages file to update the API until it was released.
An alternative would be to install jsx and then name your .js files .jsx and then once 1.2 comes out, rename it to .js and add the ecmascript package.
I’d really, really suggest having a go with Blaze first, otherwise you’re facing a pretty steep learning curve. It’d be like reading a recipe for cookies… in spanish. If you’ve made cookies before, you’re probably OK. If you know spanish, you’re probably OK. If you don’t know either, you’re gonna have a bad time.
If you still can’t be swayed, get on that devel branch & have a go 
3 Likes
Thanks, @SkinnyGeek1010 and @mattkrick!
I think I’ll give the RC a try.
@mattkrick: I’d love to use Blaze (this seems much, much simpler) but my app needs server side rendering and it seems at the moment, unfortunately, this is only possible with React.
I started getting this just now. Usually sometimes meteor would give similar crashes on windows and I could repair it by resetting the project but this time it’s not working. I’m running Windows 8.1
meteor --settings settings.json
Error: EBUSY, unlink 'C:\Users\Andreas Galster\desktop\pigmentsio\_dev\.meteor\local\build\programs\server'
at Object.Future.wait (C:\Users\Andreas Galster\AppData\Local\.meteor\packages\meteor-tool\1.1.7-rc.12\mt-os.windows
.x86_32\dev_bundle\lib\node_modules\fibers\future.js:398:15)
at Object.rm_recursive (C:\tools\fs\files.js:270:9)
at Object.files.rename (C:\tools\fs\files.js:1406:13)
at Object.files.renameDirAlmostAtomically (C:\tools\fs\files.js:812:11)
at Builder.complete (C:\tools\isobuild\builder.js:571:13)
at C:\tools\isobuild\bundler.js:1913:13
at C:\tools\isobuild\bundler.js:1930:7
at C:\tools\isobuild\bundler.js:2199:22
at C:\tools\utils\buildmessage.js:268:13
at [object Object]._.extend.withValue (C:\tools\utils\fiber-helpers.js:114:14)
at C:\tools\utils\buildmessage.js:261:29
at [object Object]._.extend.withValue (C:\tools\utils\fiber-helpers.js:114:14)
at C:\tools\utils\buildmessage.js:259:18
at [object Object]._.extend.withValue (C:\tools\utils\fiber-helpers.js:114:14)
at C:\tools\utils\buildmessage.js:250:23
at [object Object]._.extend.withValue (C:\tools\utils\fiber-helpers.js:114:14)
at Object.capture (C:\tools\utils\buildmessage.js:249:19)
at Object.exports.bundle (C:\tools\isobuild\bundler.js:2047:31)
at C:\tools\runners\run-app.js:551:36
at time (C:\tools\tool-env\profile.js:232:28)
at Function.run (C:\tools\tool-env\profile.js:377:12)
at bundleApp (C:\tools\runners\run-app.js:541:34)
at [object Object]._.extend._runOnce (C:\tools\runners\run-app.js:594:35)
at [object Object]._.extend._fiber (C:\tools\runners\run-app.js:858:28)
at C:\tools\runners\run-app.js:396:12
- - - - -
and meteor reset:
C:\Users\Andreas Galster\AppData\Local\.meteor\packages\meteor-tool\1.1.7-rc.12\mt-os.windows.x86_32\dev_bundle\lib\node
_modules\fibers\future.js:278
throw(ex);
^
Error: EBUSY, unlink 'C:\Users\Andreas Galster\desktop\pigmentsio\_dev\.meteor\local\build\programs\server'
at Object.Future.wait (C:\Users\Andreas Galster\AppData\Local\.meteor\packages\meteor-tool\1.1.7-rc.12\mt-os.windows
.x86_32\dev_bundle\lib\node_modules\fibers\future.js:398:15)
at Object.rm_recursive (C:\tools\fs\files.js:270:9)
at Command.main.registerCommand.name [as func] (C:\tools\cli\commands.js:1206:9)
at C:\tools\cli\main.js:1377:23
- - - - -
PS C:\Users\Andreas Galster\desktop\pigmentsio\_dev> meteor --settings settings.jsonSince updating to rc12 I haven’t seen the build get stuck on the unexpected token error in .jsx, but I have seen the same problem happen less frequently with other jsx errors, e.g. duplicate declaration.
Was there a fix made for this or did it just go away (partially) on its own? I looked for a related change but couldn’t find anything; maybe I’m looking in the wrong place.
Unfortunately, even though this happens much less frequently now, I now need to rm -rf .meteor/local/bundler-cache to get going again as it seems to like to pick the wrong version from the cache if given the chance.
Same problem. Should not be so hard for them to list the conflicts since it is going through the package list anyway…
This is actually one of the things that’s improved in Meteor 1.2.
This would be really cool, indeed!
anyone has tried to build for android ?
I failed to do the build with rc12 (and rc11).
on a meteor app 1.1.0.3, this will work fine : meteor build /tmp --server localhost:3000
On the same app, i upgrade to 1.2-rc.12 and i run the same command line, then i have an error
=> Errors executing Cordova commands:
While listing platform versions in Cordova project:
Error: Command failed:
/home/rebolon/workspaces/mobile1.2/.meteor/local/cordova-build/platforms/android/cordova/version
/usr/bin/env: node: No file or folder
I have noticed that RC1.2 doesn’t minify the app when building (or running --production).
What’s new in RC 14?
1 Like
Is it me, or is there no (noticeable) difference in build times in 1.2 vs 1.1?