Release 1.6 #8728
Release 1.6 #8728
Conversation
|
Migrating my to-do list from a comment in the old PR:
I know I'm forgetting important items here, so please feel free to comment with anything else you can think of! |
|
Node.js 8 was released a few hours ago, how about landing that and npm v5 at the same time? ;) |
|
And perhaps more importantly for meteor: N-API, giving a stable Application Binary Interface (ABI) across different Node.js versions. |
|
Node 8 is supposed to be the next LTS, so it might be good to jump straight to eight if it's not a huge amount of work. |
|
I'm not opposed to Node 8, though it was released only just this morning, and in my experience the Node/npm ecosystem can take a while to adjust to a new Node/V8 version. I welcome you to modify |
|
Any plans of upgrading the build tool to improve the developer experience regarding frontend development? I have seen so much people migrating from Meteor to Next.js, which is awesome for building user interfaces in React, thanks to its amazing Hot Module Replacement implementation (HMR) that allows to see code changes instantly. Also it has out of the box SSR support. I've seen a plugin or so being implemented for Blaze in the forums, but not for React. My opinion is that most people will prefer first to have those improvements (first class HMR and SSR) than a node upgrade. Next.js version 3 beta came out a few days ago, and it came with dynamic imports and the ability to create a static version of your app. I am wondering if using Meteor-Client-bundler on a Next.js v3 app and a Meteor server is the perfect stack to develop my next webapp. |
|
Just want to give a quick thumbs up for the overview of this release. You've summarized very well what you're going to do and also how we can figure out when there's a new build, I like it! |
|
@vladejs Now that 1.5 is out, one of my next agenda items is to demonstrate how easy SSR + routing + dynamic imports can be with React in a Meteor app, but I don't think this is the right forum to discuss that. I'm sure there will be a Release 1.5.1 pull request before long. Also Next.js is entirely React-specific, whereas Meteor is a general purpose build tool, so I think you're comparing apples to an apple tree, if you get my drift… |
|
I tried a Meteor build with Node 8 and npm 5 just now, and I couldn't find any obvious problems. If anything, it's faster and uses less memory. Native async/await would be 😚👌. |
|
If I could place a wish for a next "banner feature" that would be first-class support for new platforms like "react-native" or "desktop (electron)": #8615 this would move meteor one step more ahead! |
|
@macrozone I'm not sure it'll hit the mark for 1.6 but any help you could provide in addressing the action items identified in that issue you've linked to would certainly be helpful in achieving that goal (which I agree would be great!), in particular, the SockJS-factor (#8621). |
|
Can confirm @benjamn. Just tried to run Meteor with Node.js 8.0.0 on macOS 10.12.4 on a fairly large project and it runs without any obvious problems. On the build process had to remove |
Yes, this is exactly what @benjamn stated needed to be done in this comment above ^^ (4th bullet-point): #8728 (comment) |
|
Yes Ben, you are absolutely right, Next.js has very specific focus on
React. I just put it as an example of some attractive feature Meteor should
have.
You pointed out that SSR will be easily done now that 1.5 is out.
What about HMR for React apps? Is that doable in a near future?
|
|
I think actually the biggest benefit of Meteor over Next is that Next is super opinionated about routing, babel config, and more, and Meteor is a more general purpose tool even in the context of React. Built in HMR would be neat though! And of course Next also has Its advantages, so it might be a better choice for some apps! |
|
What about Graphql, Apollo dedicatedly from meteor support? I guess this was in discussion to come up with |
|
I am not a professional, so for sure, I am not the right person to judge such things and maybe I am wrong. But as a (most probably) average meteor dev I see node 6 only as a nice to have featured today. This upgrade will bring a lot for sure, but a lot of those changes will be under the hood and will not directly affect the dev process!? While HMR will significantly speed it up. It will be so much faster to develop react applications... |
Hot module replacement for React feels relatively automatic because it relies on special assumptions about React components and the React rendering process. Meteor is hardly just a tool for building React apps, and the general problem of hot module replacement is "solved" only if you're willing to attach manual event handlers to the Webpack There's still room to make Meteor rebuilds faster when only one file has changed, but much of that work already happened in Meteor 1.4.2, and further progress will not require anything like hot module replacement. |
|
Is this the right place to have a discussion about new features for meteor? I'm not saying I'm against any of these topics, but I feel like, by talking here, we're not exposing our thoughts to the majority of the Meteor community, which is located at the forums. Most of the newcomers to Meteor are in the forums, and I believe that's the place where we should be discussing this kind of things. Issues / PR feel more formal than a forum, and you need some understanding of how the internals of the project work before commenting here, or else you'll feel dumb opening issues just to be sent somewhere else. So, why don't we move this discussion to the forums, ask kindly to @benjamn, @abernix and others about their opinions with these topics there, and keep this PR thread for the progress involving making Meteor 1.6 a reality? |
|
It really isn't a good time for new features. We really need this debt of not being able to run on the latest Node.js to be paid. To anyone reading this issue's comments: Please don't request new features for this upcoming release 1.6 here. For 1.7 on, request whatever you want (in the forums or other issues' comments), but please let 1.6 finally give us the latest Node.js. |
|
Yeah this isn't the best place for feature discussions. |
|
Getting back to 1.6 and Node 6 or 8, one thing that I noticed while working on another project is that almost every ES2015+ feature I wanted to type, including async functions, are supported natively from Node 7.6+. The notable exception is Something to consider would be to intelligently choose the Babel preset for server-side code. So if there’s a preset for “Node 8,” say, that transpiles down |
|
@GeoffreyBooth native isn't necessarily faster (some features are in fact up to 23x slower with babel + node 7, and there's even one that's 2909x slower with traceur + Firefox - though presumably that one is a bad implementation). Transpiling to ES5 still makes sense I think. The comparison doesn't include Node 8 yet but I imagine many of the features will still be slightly slower than ES5. |
History.md
Outdated
| @@ -1,4 +1,4 @@ | |||
| ## v.NEXT | |||
| ## v1.5, 2017-10-30 | |||
|
🎉 🎈 🎊 🎉 🎊 🎉 🎈 🎊 1️⃣ . 6️⃣! 🎉 🎈 🎊 🎉 🎊 🎉 🎈 🎊 Meteor 1.6 is not marked as "recommended" (that is to say, the "default" for apps), but it is available to those who use the |
|
<3 |
|
tried to update to 1.6 and ran into some issues: |
|
@gregory The |
|
Great release. |
|
So what's this? When trying to install with chocolatey, it says "downloading meteor 64 bits" but instead the zip is 32bits version. See |
|
https://packages.meteor.com/bootstrap-link?arch=os.windows.x86_64 seems to give the x86_32 version still |
|
@benjamn Thanks a lot for all your hard work! |
|
@gregory Unlike Fiber(() => {
const doc = collection.findOne(...);
// do something with doc
}).run();or Promise.resolve().then(
() => collection.findOne(...)
).then(doc => {
// do something with doc
});This works because all For that matter, the Node inspector doesn't use Babel to compile the code you run, so you may notice be other differences in behavior / supported syntax, though Node 8 supports many more native ECMAScript features than Node 4. You should think of the inspector as a low-level tool for debugging raw JavaScript as it appears to Node. Perhaps a partial solution would be to run |
|
I know what i'll say is probably really bad, but we have been using underscore all over the place. I'm sure there is probably an easier way to do it, but this helped me move on. Maybe it'll help someone in the same spot. |
|
@gregory using |
|
no @hexsprite - at least not |
|
@benjamn How can I install 16 version on my windows? Install page still leads to 1.5 version :( I had wait this release to try meteor first time, I didn't want to uninstall my NodeJS 8 :) |
|
Looks like Meteor 1.6 is now recommended (see |
|
The Chocolatey |
|
@FriOne FYI Meteor bundles a pinned version of Node and npm, so Meteor will always run independent of the version of node installed on your machine |
|
When updating from 1.5.2 to 1.6 (on Windows 10), I get:
C:\Users\Ron\WraithNotes\Meteor\WraithNotes>meteor update
C:\Users\Ron\AppData\Local\.meteor\packages\meteor-tool\1.6.0\mt-os.windows.x86_32\tools\isobuild\meteor-npm.js:265
versions: _extends({}, process.versions)
^
TypeError: _extends is not a function
at Object.<anonymous> (C:\tools\isobuild\meteor-npm.js:223:3)
at Module._compile (module.js:612:30)
at Object.Module._extensions..js (module.js:623:10)
at Module.load (module.js:531:32)
at Module.Mp.load (C:\tools\tool-env\install-runtime.js:16:29)
at tryModuleLoad (module.js:494:12)
at Function.Module._load (module.js:486:3)
at Module.require (module.js:556:17)
at require (internal/module.js:11:18)
at Object.<anonymous> (C:\tools\isobuild\package-source.js:8:17)
|
|
@rcurrier666 I've seen that before, as a result of upgrading our internal Babel plugins to version 7, though I don't know what would be causing it now. Can you open a new issue for that? |
|
In order to respect the time and attention of the 79 awesome people who have contributed to this issue over the last five months, I'm going to turn off further commenting on this thread now. Please open new issues if you encounter any problems updating to Meteor 1.6. Thanks again, everyone! |
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:
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
--inspectflag 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 runmeteor update --release 1.6-beta.nto update an existing app to the new version, ormeteor create --release 1.6-beta.n your-new-appto 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.6branch, regenerate the dev bundle, and run themeteorscript 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 --helpSee these instructions for help with running Meteor from a checkout.
Left to do:
meteor debugto use Chrome DevTools instead ofnode-inspector(👋 @brucejo75), which is such a better debugging experience it's not even funny.meteor-toolto build on Linux 32bit (runs out of memory currently).meteor-toolto 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.Consider removing or reducing the use ofConsidered, and postponed until it matters.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 themeteor-promisepackage (which was the key to getting the tests to pass today).babel-plugin-transform-es2015-modules-reify.npmto version 5, and teachtools/isobuild/meteor-npm.jsto work withpackage-lock.jsonfiles instead ofnpm-shrinkwrap.jsonfiles. Merged.