Meteor 1.8.1 released 🎉

[storyteller]

If you haven’t noticed Meteor 1.8.1 has been released. Here is the list of changes from the history file:

v1.8.1, 2019-04-03

Breaking changes

• Although we are not aware of any specific backwards incompatibilities,
  the major upgrade of cordova-android from 6.4.0 to 7.1.4 likely
  deserves extra attention, if you use Cordova to build Android apps.

Migration Steps

N/A

Changes

• Node has been updated from version 8.11.4 to version
  8.15.1, an important
  security release,
  which includes the changes from four other minor releases:

  • 8.15.0
  • 8.14.0, an important
    security release
  • 8.12.0
  • 8.13.0

  Note: While Node 8.12.0 included changes that may improve the
  performance of Meteor apps, there have been reports of CPU usage spikes
  in production due to excessive garbage collection, so this version of
  Meteor should be considered experimental until those problems have been
  fixed. Issue #10216

• The npm tool has been upgraded to version
  6.9.0, and our
  fork of its
  pacote dependency has been updated to version 9.5.0.

• Mongo has been upgraded to version 4.0.6 for 64-bit systems (was 4.0.2),
  and 3.2.22 for 32-bit systems (was 3.2.19). The mongodb npm package
  used by npm-mongo has been updated to version 3.1.13 (was 3.1.6).

• The fibers npm package has been updated to version 3.1.1, a major
  update from version 2.0.0. Building this version of fibers requires a
  C++11 compiler, unlike previous versions. If you deploy your Meteor app
  manually (without using Galaxy), you may need to update the version of
  g++ used when running npm install in the bundle/programs/server
  directory.

• The meteor-babel npm package has been updated to version 7.3.4.

• Cordova Hot Code Push mechanism is now switching versions explicitly with
  call to WebAppLocalServer.switchToPendingVersion instead of trying to
  switch every time a browser reload is detected. If you use any third
  party package or have your own HCP routines implemented be sure to call
  it before forcing a browser reload. If you use the automatic reload from
  the Reload meteor package you do not need to do anything.
  cordova-plugin-meteor-webapp PR #62

• Multiple Cordova-related bugs have been fixed, including Xcode 10 build
  incompatibilities and hot code push errors due to duplicated
  images/assets. PR #10339

• The cordova-android and cordova-ios npm dependencies have been
  updated to 7.1.4 (from 6.4.0) and 4.5.5 (from 4.5.4), respectively.

• Build performance has improved (especially on Windows) thanks to
  additional caching implemented by @zodern
  in PRs #10399,
  #10452,
  #10453, and
  #10454.

• The meteor mongo command no longer uses the --quiet option, so the
  normal startup text will be displayed, albeit without the banner about
  Mongo’s free monitoring service. See this
  MongoDB Jira issue
  for more details.

• In Meteor packages, client/ and server/ directories no longer have
  any special meaning. In application code, client/ directories are
  ignored during the server build, and server/ directories are ignored
  during the client build, as before. This special behavior previously
  applied to packages as well, but has now been removed.
  Issue #10393
  PR #10414

• If your application is using Git for version control, the current Git
  commit hash will now be exposed via the Meteor.gitCommitHash property
  while the app is running (in both server and client code), and also via
  the "gitCommitHash" property in the star.json file located in the
  root directory of builds produced by meteor build, for consumption by
  deployment tools. If you are not using Git, neither property will be
  defined. PR #10442

• The Meteor Tool now uses a more reliable method (the MongoDB
  isMaster command)
  to detect when the local development database has started and is ready to
  accept read and write operations.
  PR #10500

• Setting the x-no-compression request header will prevent the webapp
  package from compressing responses with gzip, which may be useful if
  your Meteor app is behind a proxy that compresses resources with another
  compression algorithm, such as brotli.
  PR #10378

Coming up next is Meteor 1.9 for which we already have a milestone:

meteor/meteor

And finally don’t forget to check out a new blog post on the Meteor Blog from @pcorey :

Putting the Brakes on NoSQL Injection with Secure Meteor

[minhna]

AWESOME! To all contributors, thank you very much.

[jwentwistle]

Thank you for all the updates! Can meteor be made to update node (npm, etc) independent of meteor?

[jorgeer]

Woop! Looking forward to updating to this.

[rjdavid]

Awesome job to everyone involved. Thank you.

[trusktr]

Removing traditional client/server folder support in packages is a breaking change. Not only will some apps break, but it may be time consuming to replace packages relying on this behavior. Keep in mind there are projects that use local packages to organize app code.

[captainn]

There are advantages in the way Meteor ties closely to a specific version of node.js. See this Meteor blog post on the subject.

[ppillip]

AWESOME! thank you very much.

But try to do this :

“meteor add coffeescript”.

It doesn’t work properly.

[copleykj]

I would say that this could be considered a breaking change if this was documented as the way isobuild worked or the way packages were supposed to be structured, but being a package author since around v0.6.5, I’ve never seen this to be the case.

It is unfortunate that package authors have relied on an undocumented way that isobuild worked and deviated from the documented API.

[ggerber]

Yay!!!

Thanks to all involved!

[alawi]

It is unfortunate that package authors have relied on an undocumented way that isobuild worked and deviated from the documented API.

The use case where this has a significant impact is not for package authors but for projects that follow package based architecture, and even more importantly, isomorphic end-to-end packages. Since folks have been splitting their projects into isomorphic packages, something which I think the Meteor community pioneered, then I’d argue that the speed and behavioural consistency of the rebuilds during development within the packages is as important as the development in the main project.

But I’d agree that technically this is not breaking change since the behaviour was rather assumed. Nevertheless, given it’s demonstrated usefulness, I’m hoping we can get something official back, I’m personally hesitant to update due to this change.

[hwillson]

@trusktr @alawi Would one of you be able to open a GH issue about this, so it doesn’t get lost here? Thanks!

[alawi]

Yes, I think this is tracked on this issue and here as well.

If I understood correctly, it seems benjamn has something more flexible/generic in mind so I’m optimistic!

[globalise]

Have just built a successful application with 1.8.1 with full integration with a backend API in less than 1 weeks in my after work hours. Meteor remains awesome! Thanks for your efforts!

[kartboy16]

THIS IS FANTASTIC!!!

I was on 1.6 and to be honest, the slow local rebuilds were taking it’s toll on me. This may sound corny but the fast rebuilds/delayed legacy builds in 1.8 have made development fun again.

THANKS FOR ALL THE WORK EVERYONE!!