Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release 1.8.2 #10522

Open
wants to merge 234 commits into
base: master
from

Conversation

@benjamn
Copy link
Member

commented Apr 10, 2019

Meteor 1.8.1 has been released and recommended 馃帀 馃尞 馃挮, and (as always) the outstanding issues/features fall into two categories:

  • those we can fix/implement by releasing updates to Meteor packages (Package patches), and
  • those that will require a follow-up Meteor release, because they involve changes to the meteor/tools codebase (including the dev bundle), or because they involve significant changes to core packages that we want to avoid releasing until the next Meteor release.

Meteor 1.8.2 (this PR) will bundle up any urgent bug fixes or minor improvements that require a new Meteor release. Feel free to target the release-1.8.2 branch instead of devel with any PRs that seem to fit this description, or we can help you make that decision if you're unsure.

As anyone following Meteor development recently will realize, community input matters a LOT when it comes to deciding what goes into a release, and when it's time to stabilize/finalize it. We welcome that input, and we will do our best to release Meteor 1.8.2 as soon as it's clear it solves specific real problems for Meteor developers.

There will also soon be a Meteor 1.9 pull request for more experimental changes, such as (potentially, but not limited to) upgrading Node.js. Let us know if you think we've mistakenly put something into the 1.9 Milestone that belongs in 1.8.2, or vice-versa!

benjamn and others added 9 commits Apr 3, 2019
Bump ecmascript version to 0.12.7.
This version was published specifically using Meteor 1.8.1, so that it
includes babel-compiler@7.3.4 instead of 7.2.4.
Update cordova-plugin-meteor-webapp to version 1.7.0 (#10520)
* Update cordova-plugin-meteor-webapp to version 1.7.0.

Fixes #10516.

* Bump meteor-tool and webapp to a temporary 1.8.1-issue-10516.0 version.

I attempted to publish webapp@1.7.4-rc.0 with @rj-david's changes from
meteor/cordova-plugin-meteor-webapp#78 to verify
that they fix #10516, but prerelease versions like 1.7.4-rc.0 are not
compatible with non-prerelease core package constraints like ~1.7.3 (which
desugars to >=1.7.3 <1.8.0), as explained by this comment in the semver
source code: https://github.com/npm/node-semver/blob/5fb517b2906a0763518e1941a3f4a163956a81d3/semver.js#L1246-L1250

While this behavior was somewhat surprising to me, I haven't come up with
a way to fix it without accidentally allowing any prerelease version of
core Meteor packages to be installed in applications using an official
(non-prerelease) version of Meteor.

Instead, we can just cut a temporary prerelease version of Meteor itself.
If that fixes the problem, then we can publish webapp@1.7.4 safely,
without actually publishing a Meteor 1.8.1.1 release just for this.

* Update webapp to version 1.7.4 (without -issue-10516.0 suffix).
Merge pull request #10517 from meteor/update-meteor-babel-to-7.4.3
Use meteor-babel@7.4.3 to compile meteor/tools (but not application or package code, yet).

@benjamn benjamn added the in progress label Apr 10, 2019

@benjamn benjamn added this to the Release 1.8.2 milestone Apr 10, 2019

@benjamn benjamn self-assigned this Apr 10, 2019

benjamn added 2 commits Apr 10, 2019
Update optimism and use noContext to isolate Fiber contexts.
The optimism package no longer knows anything about Fibers, but it does
export various helpers for managing execution contexts, one of which
(noContext) allows us to censor the current context for the duration of a
function call. By wrapping Fiber.yield with noContext, we keep distinct
Fibers from accidentally registering cache dependencies on one another.

@benjamn benjamn changed the base branch from devel to master Apr 10, 2019

benjamn added 6 commits Apr 10, 2019
@rj-david

This comment has been minimized.

Copy link

commented Apr 12, 2019

Seems like the original issue was closed so I'm not sure if this is the right thread. For the recent release to fix the xcode and swift issues, are we keeping that release or are we expected to roll it to 1.8.2? I remember reading that it was just temporary so I am not sure if we should move all our projects now to that version or wait for 1.8.2 or should it automatically roll into 1.8.1 once the plugin is updated.

@benjamn

This comment has been minimized.

Copy link
Member Author

commented Apr 12, 2019

@rj-david That release was just a way to test the cordova-plugin-meteor-webapp@1.7.0 changes before publishing a new version of webapp. I believe updating to webapp@1.7.4 will solve the problem now, unless there were other changes required within Meteor?

benjamn added 7 commits Apr 11, 2019
Implement basic meteor/context package with @wry/context.
The promise package needs a weak dependency on this package (on the
server) because meteor-promise saves a reference to Fiber.yield, so we
need to have wrapped Fiber.yield with noContext before that happens.
Enable Babel-powered TypeScript compilation of meteor/tools.
These changes pave the way for incrementally converting the implementation
of Meteor's command-line tool to TypeScript, which should have profound
benefits for self-documentation via types, as well as substantially
improving navigability and approachability for community contributors.

Just imagine being able to auto-complete the fields of the various
File-like classes currently floating around the codebase, instead of
having to track down their implementations every time. TypeScript was
designed with large projects like Meteor in mind, and it seems
increasingly irresponsible to forgo the benefits of a type system by
relying on the expertise of a few core contributors who know the codebase
inside and out. I am one of those few people, and I am very excited to
have the assistance of a type system, so I can only imagine how
transformative and empowering it will be for everyone else.

If you've ever wanted to get involved in core Meteor development, picking
a few meteor/tools modules to convert to TypeScript is a great way to get
to know that part of the codebase, while also making things easier for
everyone else who interacts with that code in the future.

Because we already compile meteor/tools using Babel, it makes the most
sense to use Babel's @babel/preset-typescript to compile .ts files:
https://babeljs.io/docs/en/next/babel-preset-typescript.html

Using Babel also means we get to keep all of our current advanced
compilation strategies, such as using Reify to compile module syntax:
https://www.npmjs.com/package/reify

Since we're using Babel, the meteor/tools/tsconfig.json file exists mostly
for the benefit of external tools like VSCode, rather than as a source of
truth for compilation behavior.

Despite our existing convention of including explicit .js file extensions
when importing modules, TypeScript and VSCode strongly encourage omitting
the file extension, so the import can be resolved to a .ts file in
development or a .js file when compiled. Although I find this ambiguity
somewhat unfortunate, it makes sense to follow community norms, at least
until Node.js begins supporting .ts modules by default.
benjamn added 6 commits Sep 6, 2019
Update typescript version to 3.6.2.
Most of these changes came for free with the update of meteor-babel to
version 7.6.0, but a few remaining spots needed to be updated.
Use json5 for optimisticReadJsonOrNull.
Because json5 is more tolerant of non-standards-compliant input, it has no
trouble with \t tab characters outside of string literals, so this change
should fix issue #10688.

Note that json5 is already installed in dev_bundle/lib/node_modules/json5,
because it is a dependency of @babel/core, so we don't need to rebuild the
dev bundle immediately, though it would be a good idea to do so before the
next beta/RC release.

@benjamn benjamn force-pushed the release-1.8.2 branch from c717196 to 5124cb4 Sep 8, 2019

@benjamn

This comment has been minimized.

Copy link
Member Author

commented Sep 10, 2019

Are there additional features that folks would like to see implemented before we transition to the (hopefully short) Release Candidate phase of testing? Bear in mind that Meteor 1.8.2 will be released sooner if we start the RC phase sooner, and that we can still fix bugs discovered during the RC phase.

@rj-david

This comment has been minimized.

Copy link

commented Sep 10, 2019

@benjamn, thanks for pushing this towards RC soon. In react 16.9, withTracker returns warnings due to the use of deprecated lifecycles. Any chance that the related PRs be included?

@arggh

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2019

Are there additional features that folks would like to see implemented before

Not sure if this is a feature request or bug report, but I'd really appreciate getting a rebuild when changing files inside app/client/node_modules: #10664

I was hoping this would have been tackled in 1.8.2, since a lot of effort related to bundling/caching seems to have been made recently, and therefore the mental burden of starting 1.8.3 with work related to bundling/caching would be just too much to ask... but that's just me guessing.

(I just noticed the Impact: few label on the issue, so my hopes are diminishing...)

@arggh

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2019

Also, we've had a production app running 1.8.2-beta.17 for a month now with no apparent issues at all 馃挴

@CaptainN

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2019

@benjamn Can we get npm modules with "svelte" entry points defined in package.json added to the recompile list automatically? Svelte modules ship uncompiled source with a link in package.json, so I've been having to add them to the recompile configuration area in my own config.

@brucejo75

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2019

#10543 would be great to merge. I needed your feedback on the current status.

@sakulstra

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2019

#10527 (comment) any chance of updating to node 10 (as I fear 1.9 won't happen within the next 3 weeks)

@benjamn

This comment has been minimized.

Copy link
Member Author

commented Sep 10, 2019

In react 16.9, withTracker returns warnings due to the use of deprecated lifecycles. Any chance that the related PRs be included?

@rj-david Is this related to all the work that @CaptainN and others have been doing in meteor/react-packages#273, or (hopefully) something easier? In either case, we should be able to fix React-related issues with package updates, independent of the Meteor release, so I don't consider this a blocker for 1.8.2 (which is good news).

Not sure if this is a feature request or bug report, but I'd really appreciate getting a rebuild when changing files inside app/client/node_modules: #10664

@arggh Commented in the issue: #10664 (comment)

Can we get npm modules with "svelte" entry points defined in package.json added to the recompile list automatically?

@CaptainN I'd rather not hard-code a framework-specific exception, assuming the workaround is just to add the package(s) manually to the meteor.nodeModules.recompile list. That said, I've recently been wondering if there's a reliable-ish way to detect that an import failed at runtime because the imported package needs to be recompiled, which would be an opportunity to show a helpful error message. Any thoughts on that?

#10543 would be great to merge. I needed your feedback on the current status.

@brucejo75 I agree with your analysis there, and I'm sorry that PR has been sitting unmerged for so long. There's a bit more of a backstory that I should be able to explain soon (nothing you did or didn't do). For what it's worth, I think it would be safe to release that change in a patch update to the accounts-base package, so it's not technically a 1.8.2 blocker (again, I hope this comes as good news, not an excuse for inaction).

#10527 (comment) any chance of updating to node 10 (as I fear 1.9 won't happen within the next 3 weeks)

I would honestly rather ship Node 12 in three weeks than spend any time debugging all the weird ways in which Node 10 is not exactly the average of 8 and 12. Put another way, it's a good thing when there's less diversity in application configurations and dependencies (e.g. fewer major Node versions), because then more of our problems will be the same as someone else's, and we can solve them together more easily.

@CaptainN

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2019

@benjamn

the work that @CaptainN and others have been doing in meteor/react-packages#273, or (hopefully) something easier?

An easier, and shorter term solution might be to simply replace the use of componentWillMount with UNSAFE_componentWillMount which will quiet the warning, and will continue to be supported into the next major version of React. It might even make sense to keep the withTracker hook on that while we roll out the hook (which I think is worth reviewing, because the hook is nicer to work with). But we can discuss all that in the other PR.

@CaptainN

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2019

@benjamn I'm not sure how you'd detect an error. It throws up a parse error (I think) - can that be detected, and restarted?

Rather than adding framework-specific exceptions, is there a way (or can it be added) for build packages to add this capability themselves? If so, the meteor-svelte (svelte:compiler) package authors could set it up.

@honwlt

This comment has been minimized.

Copy link

commented Sep 11, 2019

cordova platform updates would be very helpful.
eg. #10626

@JanMP

This comment has been minimized.

Copy link

commented Sep 11, 2019

@benjamn Mongo 4.2 got some additional features for aggregation pipelines that would solve quite a few problems for me.

@rj-david

This comment has been minimized.

Copy link

commented Sep 11, 2019

@benjamn

the work that @CaptainN and others have been doing in meteor/react-packages#273, or (hopefully) something easier?

An easier, and shorter term solution might be to simply replace the use of componentWillMount with UNSAFE_componentWillMount which will quiet the warning, and will continue to be supported into the next major version of React. It might even make sense to keep the withTracker hook on that while we roll out the hook (which I think is worth reviewing, because the hook is nicer to work with). But we can discuss all that in the other PR.

Here is the stop-gap PR just to remove the disruptive notifications from react 16.9: meteor/react-packages#274

@rj-david

This comment has been minimized.

Copy link

commented Sep 11, 2019

@benjamn Mongo 4.2 got some additional features for aggregation pipelines that would solve quite a few problems for me.

@JanMP, we are using rawCollection()

@JanMP

This comment has been minimized.

Copy link

commented Sep 11, 2019

@JanMP, we are using rawCollection()

Duh. But that doesn't magically give you Mongo 4.2 features on the dev server. And I'd rather not deploy code that breaks stuff in my development environment.

@brucejo75

This comment has been minimized.

Copy link
Contributor

commented Sep 11, 2019

@JanMP, very easy to set up your own mongo server and connect via the environment variable: MONGO_URL.

I would argue that for development this is preferred. Then meteor reset doesn't toast your DB & you can run any mongo version you like.

@morloy

This comment has been minimized.

Copy link
Contributor

commented Sep 11, 2019

I would honestly rather ship Node 12 in three weeks than spend any time debugging all the weird ways in which Node 10 is not exactly the average of 8 and 12. Put another way, it's a good thing when there's less diversity in application configurations and dependencies (e.g. fewer major Node versions), because then more of our problems will be the same as someone else's, and we can solve them together more easily.

We can also ship Node 12 in 1.8.2 馃榿

@rj-david

This comment has been minimized.

Copy link

commented Sep 11, 2019

We can also ship Node 12 in 1.8.2 馃榿

It will be counterproductive as we have been beta testing Node 12 in 1.9

It will be faster that we move 1.8.2 out of the gate soon, and then move to beta and then RC with 1.9

@CaptainN

This comment has been minimized.

Copy link
Contributor

commented Sep 11, 2019

1.8.2-beta.17 continues to be multiple times slower than 1.8.1 is. I'm not sure what changed, but if I go back to 1.8.1, everything is fast again - at least on my largish main project (pixstoriplus.com). Working on a svelte starter which doesn't have much in it is FAST.

@pmogollons

This comment has been minimized.

Copy link

commented Sep 12, 2019

@CaptainN I had the same slow down with beta 17, but with beta 18 things are fast again. You should check it out, maybe it helps you too.

@CaptainN

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2019

@pmogollons I'll try that.

@smeijer

This comment has been minimized.

Copy link

commented Sep 12, 2019

@CaptainN, I'm curious to your findings. Beta 16 is terribly slow here.

@CaptainN

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2019

@smeijer 18 seems fast again. I think I knew that at one point, then got confused, and thought 17 was the one with the fix. Sorry for the PR noise on that. The speed issues at development time are fixed.

At some point it'd be nice to get some meteor deploy speed improvements - it takes more than 1/2 hour to deploy to Galaxy, but that's a separate issue I guess.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can鈥檛 perform that action at this time.