Stuff to be removed in Meteor 2.0

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

7 Likes

This post was flagged by the community and is temporarily hidden.

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.

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

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.

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.

5 Likes

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

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.

3 Likes

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!

1 Like

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

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.

3 Likes