To China (Mainland) Users:

You should just try VPN/Shadowsocks or other things to get access to the internet, and set HTTP_PROXY, HTTP_PROXY to use your bridge to the internet. 您最好尝试使用各类工具以访问完整的互联网，并设置 HTTP_PROXY 和 HTTP_PROXY 来让 Meteor 使用您的工具。

Original Issue Content

div@dk:~$ curl https://install.meteor.com/ | sh % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 6675 0 6675 0 0 4772 0 --:--:-- 0:00:01 --:--:-- 4774 Downloading Meteor distribution ### 4.2% curl: (18) transfer closed with 168048742 bytes remaining to read

    gzip: stdin: unexpected end of file
    tar: Unexpected EOF in archive
    tar: Unexpected EOF in archive
    tar: Error is not recoverable: exiting now
    Installation failed.

EDIT: This original post talks about the upgrade to Node 6, but it was decided later on in this thread that Meteor will be upgrading to Node 8 instead. This PR now covers the Node 8 updates.

To test the Meteor 1.6 release-candidate, simply update a project by running:

meteor update --release 1.6-rc.18

Since Meteor 1.4, each release of Meteor has shipped with the latest version of Node 4. However, Node 4 is no longer under "active" long-term support (LTS) and instead falls into the "maintenance" LTS category. Node 6 is now the recommended release for most users. While Node 4 has been perfectly stable for Meteor developers for some time now, it makes sense to keep Meteor up to date.

Meteor 1.6 will be exclusively focused on upgrading the version of Node used by Meteor, along with a few must-have features that depend on Node 6, such as debugging with the --inspect flag in Chrome DevTools, and leveraging native support for new ECMAScript syntax on the server.

Development of features not dependent on Node 6 will continue along the Meteor 1.5.x version line, and those changes will be regularly merged into this pull request. Bugs pertaining to Meteor 1.6 and/or Node 6 should be filed in the Release 1.6 milestone.

This pull request supersedes #6923, where many of the initial problems with Node 6 have already been resolved. Because much of this work has already happened in parallel with Meteor 1.5, and because Meteor has previously survived an even bigger Node upgrade (Node 0.10.x to 4.x), we expect Meteor 1.6 will take significantly less time to ship than Meteor 1.5 did.

As with previous Meteor beta testing cycles, whenever you see a commit added to this pull request with a message like Bump package versions for 1.6-beta.n release., that means you can run meteor update --release 1.6-beta.n to update an existing app to the new version, or meteor create --release 1.6-beta.n your-new-app to create a fresh Meteor 1.6 app.

If you want to participate in the development of Meteor 1.6, you should check out the release-1.6 branch, regenerate the dev bundle, and run the meteor script from a checkout:

cd path/to/meteor
git fetch origin
git checkout -t origin/release-1.6
git submodule update --init --recursive
scripts/generate-dev-bundle.sh
./meteor --help

See these instructions for help with running Meteor from a checkout.

Left to do:

• [x] Release Meteor 1.5 and merge those changes into this branch.
• [x] Audit the codebase to catch up with any breaking changes between Node 4 and 5: https://github.com/nodejs/node/wiki/Breaking-changes-between-v4-and-v5
• [x] Audit the codebase to catch up with any breaking changes between Node 6 and 7: https://github.com/nodejs/node/wiki/Breaking-changes-between-v6-and-v7
• [x] Audit the codebase to catch up with any breaking changes between Node 7 and 8.
• [x] Reimplement meteor debug to use Chrome DevTools instead of node-inspector (👋 @brucejo75), which is such a better debugging experience it's not even funny.
• [x] Get meteor-tool to build on Linux 32bit (runs out of memory currently).
• [x] Get meteor-tool to build on Windows, and consider adding a 64bit Windows architecture. Note: I think both of these tasks will be easy, but as of right now our Windows build farm doesn't meet the minimum OS requirements of Node 8.
• [x] ~~Consider removing or reducing the use of Fibers in Meteor's command-line tool, though they certainly still work in Node 8, and we've managed to work around the high CPU problems caused by previous versions of the meteor-promise package (which was the key to getting the tests to pass today).~~ Considered, and postponed until it matters.
• [x] Eliminate most Babel plugins for server code, except for babel-plugin-transform-es2015-modules-reify.
• [x] Audit the codebase to catch up with any breaking changes between Node 5 and 6: https://github.com/nodejs/node/wiki/Breaking-changes-between-v5-and-v6
• [x] Upgrade npm to version 5, and teach tools/isobuild/meteor-npm.js to work with package-lock.json files instead of npm-shrinkwrap.json files. Merged.

Just as Meteor 1.4.2 took aim at rebuild performance, Meteor 1.5 will be all about production app performance, specifically client-side application startup time.

The banner feature of this effort will be first-class support for dynamic import(...), which enables asynchronous module fetching (sometimes referred to as "code splitting"). Jump to this comment for an overview of how it works.

As usual, this release will include any bug fixes since Meteor 1.4.3, though special attention will be paid to pull requests and issues that affect the performance of running applications.

You can update to the ~~latest release candidate~~ final release by running:

meteor update --release 1.5

_4 Upvotes_ I have reasonably large app that I'm working on. When I make any change to the code and press 'save', the time to build the app and refresh the browser is very long, and also highly variable. It is typically 30-60s. A colleague is working on the same app, and is using a similar machine (both are 1-2 year old high-end MacBook Pro), and in his environment the build time is typically <5s. When I make changes to a small demo project, the refresh time is <2-3s. I have tried a bunch of things, including reinstalling meteor, but to no avail. This is bringing development to its knees. What can I do?

Thank you for your help?

We're starting the process towards Meteor 1.3, with module support, better NPM integration, better file load order configuration, and more.

Meteor 1.3 gives apps full ES6 (ES2015) modules support and better NPM support. Apps and packages can now load NPM modules that are installed via npm install on client and on server. Amongst other benefits, modules let you control file load order in much more precise way than naming your files in special ways.

To get feedback early, we decided to go ahead and release a beta release that doesn't yet have all of the features ready, but does have almost complete support for modules.

Try the release by running meteor update --release 1.3-modules-beta.8 in your app directory.

@benjamn wrote a great document explaining how to use modules in Meteor.

Please start trying this release out! You can start experimenting with switching your apps or packages to use the new module features. Let us know what works well or doesn't.

Take a look at the list of changes in Meteor 1.3, and the remaining tasks.

As promised in the 1.4.1 release announcement, Meteor 1.4.2 will be all about rebuild performance, as well as the usual bug fixes post-1.4.1.

The easiest way to get involved is to keep an eye on this pull request, and run meteor update --release 1.4.2-beta.n in a test app whenever you see a new beta.n version appear. Technically, you should wait at least a half hour after you see the version appear on the releases page, since it takes a bit of time to publish the meteor-tool package for all architectures. If you've helped out with previous beta testing cycles, all of this should be familiar.

A more challenging way to get involved is to take matters into your own hands, and help improve Meteor rebuild performance. If you're up for that, we encourage you to identify specific performance problems, open issues to invite discussion of those problems, and then submit pull requests based on the outcomes of those discussions. Your pull requests should target the https://github.com/meteor/meteor/tree/release-1.4.2 branch instead of devel.

Meaningful performance work is not easy, so we really must insist on the process outlined above. Contributions that come out of nowhere are not likely to be considered or accepted, because they tend not to take the whole picture into consideration.

With that caveat out of the way, I don't think I need to convince you that build performance improvements are among the highest-impact work you can possibly do for the Meteor community. More than just improving your own developer experience, you’ll be a hero.

Here are two great documents to read to get started thinking about Meteor performance optimization:

• https://github.com/meteor/meteor/blob/devel/tools/PERFORMANCE.md
• https://medium.com/@lucashansen/faster-meteor-reloads-62cca5b56460#.rj9ysw8ut

To be clear, we are not expecting the community to do all (or even very much) of this work. Without a doubt, the core team will be working on these problems harder than anyone. If you're up for a challenge, though, we're here to support your efforts.

_45 Upvotes_ So, Node.js now has a fully merged codebase between itself and io.js and they released 4.0 which is meant to be LTS.

Since that will be the continuing track for the future, it would probably be a good idea to upgrade to node v4. But, it will be a large task since there are a lot of changes between 10.40.0 and 4.0.0.

To me, it makes sense to upgrade especially since there are built-in ES2015 features and Meteor 1.2+ is all about ES2015

EDIT: Breaking changes between 0.12 and 4.0 can be found here Breaking changes between 0.10 and 4.0 can be found here

_1 Upvote_ As you may know, we've started the process towards Meteor 1.3 last month with a beta release of the modules support and related features.

Another area of improvement for Meteor 1.3 is the Cordova integration. Because we don't want to entangle this too much with the modules work we've decided to release these changes as a separate beta for now.

Some of the changes to our Cordova integration in this beta are:

• Dependencies have been upgraded to Cordova 6.0.0, Cordova iOS 4.0.1 and Cordova Android 5.1.0.
• On iOS, we now use WKWebView by default, which should greatly improve JavaScript performance
• The file serving and hot code push plugin has been completely rewritten for reliability and performance: -Files are served from localhost instead of meteor.local. Among other things, this means the server is considered a trusted origin and web views will not block secure operations.
  • On iOS, switching to a real embedded web server allows for better caching, streaming, and source map support.
  • The plugin also allows for local file access on both iOS and Android. You can construct file system URLs manually (http://localhost:<port>/local-filesystem/<path>) or use WebAppLocalServer.localFileSystemUrl() to convert a file:// URL. On iOS, core plugins like cordova-plugin-file and cordova-plugin-camera (using Camera.DestinationType.FILE_URI) will now automatically return these URLs instead of file:// URLs
  • Downloading updates now uses native file transfer mechanisms (NSURLSession on iOS), which makes it much more reliable.
  • It only downloads changed files and does not copy files unnecessarily.
  • It makes sure to always end up with a valid version of all assets, even if downloads take a while or are resumed later.
  • It contains a safety mechanism that reverts to the last known good version when a faulty version has been downloaded (meaning it contains JavaScript errors that keep it from starting up).
• It enables support for building Android apps on Windows

You can find out more about the design of the new plugin in the README at https://github.com/meteor/cordova-plugin-meteor-webapp.

Try the release by running meteor update --release 1.3-cordova-beta.5 in your app directory.

Note that this beta also includes the changes in the 1.3 modules beta, so you may want to refer to https://github.com/meteor/meteor/issues/5788 for more information about those.

Please let us know what works well or what doesn't!

A few notes:

• iOS apps now require iOS 8 or higher, and building for iOS requires Xcode 7.2 to be installed
• Building for Android now requires Android SDK 23 to be installed
• Upgrading to a newer version of Cordova may require you to upgrade your plugin versions. We ensure core plugins use the minimum required version, but you may encounter compiler errors or undesirable behavior with third party plugins. Upgrading to newer versions of these plugins may help if they have been updated to work with recent versions of Cordova.
• When opening the generated project with meteor run ios-device, Xcode will show a dialog asking whether to Convert to Latest Swift Syntax. Make sure to click cancel here, because this conversion will leave the code in an invalid state (this seems to be an Xcode bug).
• Some of the icon and launch screen image sizes have been deprecated, so you may receive warnings about this.

"Embrace the ecosystem" http://docs.meteor.com/#/basic/sevenprinciples

I'm really happy with Blaze but it seems React is doing the same thing, why not cooperate?

• It got an official component model
• Its fast
• It renders server-side
• It does work natively on ios and android - natively...
• Meteor core team has limited ressources

Native is one killer feature on the way: react native allowing us to write js and use the native ui components.

I've been working on several meteor mobile projects, and just recently bumped to use the official cordova implementation. Its ok, but still cordova with the inconsistencies that follows.

React native is doing something a lot of us have thought about: letting us write js and leverage the native ui. Its actually allowing faster development than regular native development (eg. not having to recompile all the time)

I know some would argue that its only for mobile, but its actually also for desktop, the Meteor build tool supports multiple platforms, this is cool!

We could wrap ios/android native code in our packages instead of trying to fix the cordova plugins all the time...

https://www.youtube.com/watch?v=7rDsRXj9-cU

Just my honest opinion, I think react fits Meteor very well, maybe have a Meteor React distribution for starters to check out popularity...

Kind regards Morten

My iOS app can't use hot code push to get new versions I upload. After some searching I believe I can narrow down the problem to a bug in cordova-plugin-meteor-webapp which tries to link the same file twice. I'm pretty sure that is what breaks hot code push. I found a similar issue here: https://github.com/meteor/cordova-plugin-meteor-webapp But that repository is untouched since February so I decided to open a new issue here.

My current Meteor version is 1.7.1-rc.5, I'll try to update the meteor version to 1.8, test again and post an update here.

EDIT: After trying to build an iOS App with Meteor 1.8 I'm getting the same error

In Meteor 0.9.4 and earlier, we refreshed the package catalog at relatively unpredictable times; essentially, any time that a low level operation failed to find metadata that it was looking for. This led to behavior that was unpredictable for users and for core developers. Sometimes we would fail to refresh when refreshing was necessary; in other cases we would uselessly refresh many times per command. We were also very inconsistent as to how refresh errors were displayed and if they were treated as fatal.

For Meteor 1.0, we have implemented a much simpler approach: depending on the command, it may either never refresh, or refresh once on startup. The command can declare if an error in the refresh is fatal or not. Commands that don't deal with your local packages and app never refresh (eg 'meteor logs'). Most other commands refresh once. (In addition, long-running commands like 'meteor run' refresh every 15 minutes in the background, non-blocking.)

This is a much simpler and less bug-prone approach than the previous approach. But it has the disadvantage that some common commands like 'run' always refresh even if nothing package-related has changed. To fix this, we need to do some deeper refactorings.

Post-1.0, we will refactor build, deploy, run, debug, and test-packages to not refresh on startup. However, they will be refactored to have a centralized "make sure local packages can be parsed and the constraint solver runs successfully" point in the code, with well-defined error handling. We will ensure that it is easy to differentiate between errors that could be fixed with a refresh vs other errors. We will then put into place a much higher level version of the old retry-and-refresh: specifically, we will "refresh and retry" if the high-level "parse and solve constraints" operation fails in such a way that a refresh might help.

Errors that could be fixed with refresh:

• constraint solver not finding a solution
• api.versionsFrom unknown release (though see #2979)
• unknown package name or version in api.use
• unknown package name or version in .meteor/packages
• unknown package name or version in .meteor/versions (though this is a more recoverable error, since if we don't know something even post-refresh we can just ignore .meteor/versions)

(other examples marked with XXX #2846 in the code.)

As a workaround for now, you can disable catalog refreshing entirely by setting the METEOR_OFFLINE_CATALOG environment variable. This will prevent you from getting any package or release updates (including updates that will fix this bug!) so I would avoid setting it permanently for every command.

The method uses await but is not marked as async. This error is ONLY present in the release/2.9 branch, e.g. NOT in the release/2.9.1 branch which does not seem to be up-to-date nor in devel or master

methods.getNewToken = function () {
      const user = accounts.users.findOne(this.userId, {
        fields: { "services.resume.loginTokens": 1 }
      });
      if (! this.userId || ! user) {
        throw new Meteor.Error("You are not logged in.");
      }
      // Be careful not to generate a new token that has a later
      // expiration than the curren token. Otherwise, a bad guy with a
      // stolen token could use this method to stop his stolen token from
      // ever expiring.
      const currentHashedToken = accounts._getLoginToken(this.connection.id);
      const currentStampedToken = user.services.resume.loginTokens.find(
        stampedToken => stampedToken.hashedToken === currentHashedToken
      );
      if (! currentStampedToken) { // safety belt: this should never happen
        throw new Meteor.Error("Invalid login token");
      }
      const newStampedToken = accounts._generateStampedLoginToken();
      newStampedToken.when = currentStampedToken.when;
      await accounts._insertLoginToken(this.userId, newStampedToken);
      return accounts._loginUser(this, this.userId, newStampedToken);
    };

Both the synchronous and asynchronous iterators for Mongo.Cursor are defined to have a "next" argument type of never. However, TypeScript will reject using such an iterator in a for-of loop with:

Cannot iterate value because the 'next' method of its iterator expects type 'never', but for-of will always send 'undefined'.ts(2763)

This changes back to the default (undefined), which is acceptable, since the iterators ignore any arguments passed into next() anyway.

It also correctly declares the return type of dropIndexAsync, which should return a Promise, not void.

(This is an analog to the PR I submitted to DefinitelyTyped: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/63748)

Meteor version 2.9.0 Linux mint 20.3

Whenever I save a server side file in my api directory, this error appears as soon as the auto refresh happens. After looking through similar issue reports, it seems that this error is supposed to appear when said collection is getting imported more than once.

The issue I'm having is that not only are there no duplicate collection imports, this error only appears on the auto-reload (whenever I save the file). So when I start the application and am using it regularly, there is no sign of this error--indicating that this may be a development issue.

Here is what my folder structure looks like:

/imports/api/books.js

import { Meteor } from 'meteor/meteor';
import SimpleSchema from 'simpl-schema';

export const Books = new Mongo.Collection("books");

/server/main.js

import "../imports/api/books.js";

So in this case, the full error is:

HMR: Error while applying changes: Error: There is already a collection named "books"
    at Collection._maybeSetUpReplication (collection.js:314:15)
    at new Collection (collection.js:121:8)
    at eval (books.js:5:22)
    at module (books.js:713:1)
    at hot-module-replacement.js?hash=8bbefadb77097ac852d6d5dd3db9f23e39ee3511:415:7
    at fileEvaluate (modules-runtime-hot.js?hash=325e29e1f9abcee55f3cef85ec8a56670bbc6194:388:7)
    at Module.require (modules-runtime-hot.js?hash=325e29e1f9abcee55f3cef85ec8a56670bbc6194:270:27)
    at require (modules-runtime-hot.js?hash=325e29e1f9abcee55f3cef85ec8a56670bbc6194:310:21)
    at hot-module-replacement.js?hash=8bbefadb77097ac852d6d5dd3db9f23e39ee3511:602:7
    at Set.forEach (<anonymous>)

• [✓] A short, but descriptive title. The title doesn't need "Meteor" in it.
• [✓] The version of Meteor showing the problem. Meteor version: 2.9.0
• [?] The last version of Meteor where the problem did not occur, if applicable. I don;t know.
• [✓] The operating system you're running Meteor on. M2 mac Ventura 13.1
• [✓] The expected behavior. Can build!
• [✓] The actual behavior. Not work with error.
• [✓] A simple reproduction! (Must include the Github repository and steps to reproduce the issue on it.) No repository required. It's just three lines of code.

meteor create --vue test-vue
cd ./test-vue
meteor build ../ --architecture os.linux.x86_64

Then you should see something like this in action:

Hi, one option of Accounts Passwordless login is to login with user id and token.

This option is helpful when you don't have the email of this user.

But there is an inconsistent check:

This validator requires id instead of _id https://github.com/meteor/meteor/blob/4868a2bb9411b9620e640696ed2d3c400b30b12c/packages/accounts-passwordless/passwordless_server.js#L33

but the rest operator here https://github.com/meteor/meteor/blob/4868a2bb9411b9620e640696ed2d3c400b30b12c/packages/accounts-passwordless/passwordless_server.js#L16-L24 is not going to work to find the user as the id in Meteor collections is _id.

This code should check if id is in the selector and change to _id.

I never understood why Meteor had this id in Accounts packages but it does so I think it's easier to just fix the way to provide the selector to the query.

I got this problem during a YouTube Live in Portuguese so you can see how I detected the problem probably around 1hr and 15mins