Announcing Meteor 2.3.1Announcing Meteor 2.3.1: Node 14, removal of deprecated APIs, improved HMR, and much moreMeteor 2.3 & 2.3.1 bring a lot of long-expected upgrades and improvements. It also has a small diet with the removal of long deprecated code in packages which allows us to more focus on the future.Node 14 upgradeThe first major change in Meteor 2.3 is Node version upgrade to Node 14.17.3 from 12.22.1. This gets Meteor to the current LTS version of Node bringing updates in V8. Read the release article of Node 14 for more information. Some of the improvements that are present in Node 14 like new JavaScript features (like optional chaining) have been already available in Meteor.Like with any Node upgrade this will require you to review your apps to see if your dependencies are compatible with the new version. You should remove your node_modules folder and install your dependencies via meteor npm install.As with any Node update, meteor-tool dependencies also got updated, with the most notably:

• npm updated to 6.14.13 to correlate with the Node update
• fibers v5.0.0
• promise v8.1.0
• node-gyp v8.0.0
• @babel/runtime v7.14.0
• request v2.88.2
• tar v2.2.2
• sqlite3 v5.0.2
• moment v2.29.1
• underscore v1.13.1
• optimism v0.16.1
• @wry/context v0.6.0

Improved reload and HMRZodern has been hard at work making incremental improvements and fixes for HMR, most notably improving tracking of which files are used by building plugins to know when it should do a complete rebuild, a faster client-only rebuild, or completely skip rebuilding after a file is modified. This should work with any file in any directory and for both files in the app and files in packages.The most noticeable improvement is when modifying a file only used on the client. Meteor will only rebuild the client, even if the file is not inside imports or a client folder. This now removed the need to have an imports folder so that changes in the UI don’t restart the server. This was a bug introduced after the addition of meteor mainModule option in the package.json, and now it’s fixed!On the experimental side, we are testing reducing time spent by the server (re)start in development by adding a cache for Reify. This optimization is on by default in development, if you want to have it in production you can enable it by setting the METEOR_REIFY_CACHE_DIR environment variable.Accounts packages breaking changesAccounts packages got many improvements in this release cycle. While most are minor improvements or changes there are few that required a major version bump for some of the packages. This major version bump will require action from all package maintainers that depend on accounts-base, accounts-password, and oauth packages to include the new range like this: api.versionsFrom([‘1.12’, ‘2.3’]) or api.use(‘accounts-base@1.0.1 || 2.0.0’) .This is due to the removal of old APIs as described below, breaking of the enrollment workflow, and removal of SRP style password, all as described below.Enroll account workflow has been separated from reset password workflow (the enrollment token records are now stored in a separate db field services.password.enroll instead of services.password.reset). If have been doing any operations related to enrollment flow you will most likely need to change your DB queries.Finally, the old SRP-style password mechanisms from before Meteor 1.0 have been now completely removed. Other API calls from before Meteor 1.0 that have been deprecated (and now for the most part just pointing to their current equivalents) met their end in this release. See history for the full details.Removal of deprecated APIs in packagesWith the release of Meteor 2.0 it was only a matter of time until old deprecated APIs from before Meteor 1.0 would be removed. This release takes the first step focusing on removal of deprecated APIs around packages. Starting with packages API itself the old underscore style calls have been removed. So ancient calls like api.add_files will no longer work and you should used the camel case variant (api.add_files => api.addFiles).Across the entirety of core packages, any deprecated API endpoints from before Meteor 1.0 have been removed, see history for the full details. This should affect only packages and apps that have been with us since the very beginning and failed to migrate to the new API calls.Deprecated flag for packagesAmong all these removals we have a new addition for the package life cycle. In a life cycle of a package, there might come a time to end the development for various reasons, or it gets superseded. In either case, Meteor now allows you to easily notify the users of the package by setting the deprecated flag to true: deprecated: true in the package description. In addition, you can replace it with a string that tells the users where to find a replacement or what to do.The notice and instructions will display in the console when the deprecated package is added or updated.If you want to see example usage, check out the deprecated packages in Meteor.Typescript 4.3.2For fans of strongly typed JavaScript we are upgrading Typescript to 4.3.2. Check out the needed goodies:

• Separate Write Types on Properties
• override and the --noImplicitOverride Flag
• Template String Type Improvements
• ECMAScript #private Class Elements
• ConstructorParameters Works on Abstract Classes
• Contextual Narrowing for Generics
• Always-Truthy Promise Checks
• static Index Signatures
• Lazier Calculations in --incremental and --watch Compilations
• Import Statement Completions

WebApp responsesWebapp will respond appropriately to unsupported requests instead of sending content, including handling for new HTTP verbs like OPTIONS, to improve compliance in the following way:GET

• Respond with the requested resource; static asset, boilerplate etc.

HEAD

• Return headers identical to GET request
• Do not send content (It’s ignored by user agents anyway)

OPTIONS

• Respond with 200
• Send an Allow Header listing acceptable request methods
• Do not send content

CONNECT, DELETE, PATCH, POST, PUT, TRACE, etc.

• Respond with 405 Method Not Allowed
• Send an Allow Header listing acceptable request methods
• Do not send content

DDP_DEFAULT_CONNECTION_URL behavior changedThe undocumented environment variable DDP_DEFAULT_CONNECTION_URL behavior has changed. Setting DDP_DEFAULT_CONNECTION_URL when running the server (development: meteor run or production: node main.js) sets the default DDP server value for meteor. But this did not work for Cordova apps. Now you can define the Cordova app default DDP server value by setting DDP_DEFAULT_CONNECTION_URL when building.New platforms flagA new flag --platforms have been added to the meteor build command to specify the platform you want to build for. meteor build . —-platforms=android. This is useful for example when you are not using a MacOS and you want to build your app only for Android. Or you can use this to save time on CI not building all the platforms all the time.New deploy option--build-only is a new deploy option. This is helpful if you want to build first and after some validations proceed with the upload and deploy. More about this on Cloud docs.http@2.0.0Thanks to Jan Küster, the http package got a complete rewrite to use fetch internally. This is to aid you toward migration to fetch. This will allow you to use the current http API that you are used to and will continue to work. This will remove issues with deprecation of http. Though this is the end of the package and it will be now completely deprecated.New default format for Android buildsIn 2.3.1 there has been a change in the default output for Android Cordova apps. The new default format is .aab, following the announcement from Google that starting in August new apps will have to use this new format.If you still want to use the old apk format use the following flag in the build command:--packageType=apkAnd much more!And this is just the beginning, there are many other smaller fixes and improvements. Please give the changelog for Meteor 2.3 a look for a detailed list of all changes.You can update to Meteor 2.3.2 today as usual withmeteor update --release 2.3.2We had some issues with Windows and webapp package on Meteor 2.3 final version and that is why we are recommending the upgrade directly to 2.3.2.If you want to contribute for beta releases of Meteor with your feedback and testing your apps go ahead and Sign Up in our Community Slack and join our #beta-feedback channel.UPDATE 07/13/2021 — We have identified an issue when running android projects with the new bundle format. It was fixed on 2.3.2, so we recommend going directly to this versionMeteor 2.3 has been released! was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.