Stuff to be removed in Meteor 2.0

core
1

Yeah, I know another Meteor 2.0 topic, but before you start posting about your wishlist’s again STOP, this is not the topic. This topic here is to document all the deprecated APIs and code that will be removed once Meteor 2.0 sees the light of day. Given the codebase I would like to invite those who contribute to Meteor core and Meteor packages to put here their notes on anything that they see in the code as marked deprecated or backward compatibility to pre-1.0 days (which is most likely no longer used and hence is a dead code that should be removed on a breaking update to Meteor 2.0). My hope that this will make it easier to find the dead/deprecated code and remove it when the time comes or for some packages sooner.

So here goes for me (as long as I can edit this post I will keep updating it):

Packaging

Accounts

CLI

9 Likes
3

I have been looking at it but it says:

3. Strategies#

You can use multiple strategies to let your users access to your app. For now we support authentication via email/username and password, Oauth support is coming soon!

Is this really already seen as a serious alternative or is it still in it’s early days?

Edit: Based on the input I will do some more research on this package as it might be an interesting package which allow more relevant updates to the Meteor ecosystem and the wider NPM ecosystem as well.

4

I think for a hypothetical 2.0 there should be a top priority to remove pre-1.0 backward compatibility code that prevents future features moving forward. Also please consider the whole fibers debate here that also touched potential 2.0 releases.

6 Likes
5

Sure it’s a serious alternative; especially if the interest is moving towards NPM packages and less reliance on Atmosphere. The AccountsJS project grew out of Meteor, and was a multi-year refactor from the Atmosphere package manager to NPM. They removed OAuth because it was already available in libraries like Passport.js; or rather, they started with the functionality most every uses, knowing that they could leverage Passport when needed, and OAuth isn’t necessarily a one-size-fits-all approach.

That being said, sure it needs more documentation and community support for the OAuth use cases. But that‘s less difficult that it seems, and will happen simply if it’s specified as the accounts library. In the meantime, it relies on ES6 and supports REST and GraphQL transport adapters, which are much needed additions.

So, per the ‘rules’ of the thread, how about we add the Atmosphere accounts packages? If we’re going towards NPM, then the existing accounts system, as it relies on Atmosphere APIs could really stand to go. The code is a spaghetti mess and super difficult to maintain and work on.

6

For complete removal? That is pretty drastic. What I’m thinking in this thread is just listing all the deprecation notices in the codebase so that it can be removed in 2.0 no matter what the direction is going to be.

Off topic personal note: I’m thinking that maybe Meteor should adopt more of a Node approach to think. For right now that would mean that 2.0 would be compatible backward if you are not using any deprecated API. This would clean-up the code a bit and allowed us to focus on the latest version of the code. The generated press could probably attract some new people who could be instrumental in the next stages.
In 3.0 we could put in and fine tune all these breaking changes that we want to make, probably focused on just a few key areas so that we don’t have to wait years for a release. Once we were happy with the approach and things would be relatively stable with a clear migration path we would release 4.0. Rinse and repeat (with addition of LTS versions) and we’ll eventually (but more surely) get to where many would like to see Meteor.
But that is one of possible scenarios that could be done.

6 Likes
7

DDP

ddp-client:

  • client/client_convenience.js#62 (compat with 0.6.4)
  • common/livedata_connection.js#1625 (compat with 0.6.6)

ddp-server:

  • server_convenience.js#21 (compat with 0.6.4)
  • stream_server.js#122 (compat with 0.6.6)
2 Likes
8

The Meteor.Error function has some comments in it:

// This should probably be in the livedata package, but we don’t want
// to require you to use the livedata package to get it. Eventually we
// should probably rename it to DDP.Error and put it back in the
// ‘livedata’ package (which we should rename to ‘ddp’ also.)
//
// Note: The DDP server assumes that Meteor.Error EJSON-serializes as an object
// containing ‘error’ and optionally ‘reason’ and ‘details’.
// The DDP client manually puts these into Meteor.Error objects. (We don’t use
// EJSON.addType here because the type is determined by location in the
// protocol, not text on the wire.)

I would propose to create a standard way of throwing errors. The Meteor.Error is lacking a bit in scenario’s like using it in REST API’s (throwing with statuscode) and that’s probably also why ValidationError was invented.

4 Likes
9

Please, keep Meteor backward compatible. For many project it can destroying. Look a React. There are very careful about updating and deprecating of old stuff. Long life to Meteor!

3 Likes
10

Doing as much as possible. Though at some point you must remove deprecated code that has been lurking around for years. Not all. Just the stuff that is holding back the project. Having said that, the goal is to make it either backwards compat or to provide at least some form of smooth transitioning

2 Likes
11

Please read the opening post. This topic is about documenting API that is deprecated. Major versions by definition (if we follow semantic versioning) remove API like this. If you look on the API we talk here about it is usually with reference to 0.x versions. Version 2.0 is an opportunity to remove this deprecated code and do a general audit so that we can move the project forward as @cloudspider mentioned.

5 Likes
12

I’m right now crawling trough the babel compiler package and noticed that it has typescript stuff contained in it. I would expect that to be located in the typescript package - which is now virtually empty. Maybe a good thing to note, because what if we want to support another superset of Javascript using a package?

Here’s the snippet that loads the tsconfig if present: https://github.com/meteor/meteor/blob/96423dbd959b42d5869ca2a3fcd834700ad0e7be/packages/babel-compiler/babel-compiler.js#L218

1 Like
13

Breaking changes are necessary to push things forward. React has only gotten better over the years.

4 Likes
14

But React still has classes, they could remove them and 90% of all projects could go to the garbage. That is why I stopped to user Angular after incompatibility after 1.x. I am not agains changes, but very small and over time to be possible to change code base without any hast.

15

I don’t think this will happen, the day they drop classes support (which I still like in many cases due to the clear encapsulation coming from OOP) is the day React will be forked.

Frontend library developers need to keep in mind the economical, community and business environments surrounding those tools. Just because a library has a little better syntax or little smaller or littler faster will not convince many experienced engineers and business people to migrate their entire code base with little improvement to their customers (coupled with risks, costs, pain and even potential regress). That is why Blaze is still thriving, it got the job done and many successful (i.e paid) projects were built on it.

3 Likes
16

What about React.Component? React has evolved and left things behind.

17

You are right, some things because unsafe, and still work, it will take long time when it is gone. Community needs time to adopt changes. I am against to switch to version 2 and left all old things behind. I think we do not need to argue more about it here. :slight_smile:

18

I think @podeig concern is about React.Component being deprecated at some in the future. It is a valid concern since there is a pressure to decrease react bundle size, and in my mind, this will be a foolish move as I explained in my comment above.

Perhaps the key to making those critical decisions successfully is to deeply understand the ecosystem (past and future trends via surveys and packages usage, etc.) and engage the community in the discussion (which is what @storyteller is doing very well!). In retrospect, Meteor has been really great at backward compatibility thus far, it is just impressive how much Meteor evolved without major breaking changes, I think this is amazing engineering so far and one the biggest selling point for Meteor.

Edit: sorry for going off on a tangent.

2 Likes
20

React is small enough already: react + react-dom is 109 kb (34.8 kb gzipped). Who cares now how big it is: 100kb or 200kb, and with every year it becomes less and less interesting. :slight_smile:

Agree with the second part of your last post. :+1:

1 Like
21

Though the topic is nice, it is discussed in different other threads. Lets keep this one to create a list of things that need to be removed or done for v2 :slight_smile:

2 Likes
22

They deprecated most of the problematic lifecycle methods on React.Component which have no hooks analog, and will soon remove them all. At that point, there is no reason React.Component can’t become a simple wrapper around a “stateless” functional implementation. I bet that’s more likely to happen than removing it.

2 Likes