Meteor 1.8.1 released 🎉

announce
1

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:

    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:

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

49 Likes
2

AWESOME! To all contributors, thank you very much.:smiling_face_with_three_hearts:

3 Likes
3

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

4

Woop! Looking forward to updating to this.

2 Likes
5

:clap::clap::clap:

Awesome job to everyone involved. Thank you.

2 Likes
6

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.

6 Likes
7

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

3 Likes
8

AWESOME! thank you very much.

But try to do this :

“meteor add coffeescript”. :frowning:

It doesn’t work properly.

1 Like
9

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.

1 Like
10

Yay!!!

Thanks to all involved!

1 Like
11

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.

1 Like
12

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

5 Likes
13

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!

3 Likes
14

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!

10 Likes
15

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!!

:clap:

4 Likes