allow 'sys' to be an alias for 'util'

[bcantrill]

In the migration of Joyent's extensive node-based software stack to 0.8, we have found one of the most tedious (and enraging) issues to be the removal of 'sys' for 'util'. Yes, we know that this has been deprecated for quite some time -- but it doesn't change the fact that 'sys' has worked and that making this change was excruciatingly painful. (No, we didn't decide to assign 'sys' to the results of "require('util')" -- and if that were the recommendation, wouldn't that undermine the putative rationale for the removal of 'sys'?) To quantify the effect: we had to make thousands of changes across tens of repos -- changes that were exasperating, to say the least (with great opportunity for a slip-up that wouldn't manifest itself until, say, a critical error message resulted in an uncaught exception). History has taught us that the issues that we at Joyent experience are likely to be experienced by the broader node base; for this reason, we believe that 'sys' should be permitted as an alias for 'util' for the indefinite future.

[isaacs]

I'm sort of +1 on this, maybe even in 0.8.

1. It does not change ABI.
2. "sys" is undocumented, and therefor an internal API.
3. It won't break any programs to add module.exports = require('util'); as a sys module, and it will make some work.
4. This is like 80% of the complaining I'm hearing about 0.8, and it's completely ridiculous. We should just declare that the throw is a bug, and call this a bugfix.

We put a few rounds in sys already. It'll probably die on its own. Is it really necessary to make it throw?

[isaacs]

(push was to reviewme branch, should not close this.)

[defunctzombie]

I think it depends on how you feel about module deprecation in core. There are those out there that will say that once you ship code you must never break backwards compat, but I think this is a bit of a farce since things change over time and there are cleaner and better ways to do it.

I don't find the two cycle deprecation that unreasonable. Personally, if a module author can't be bothered to keep their module up to date, I think this is grounds for removal from npm. Modules shouldn't go to npm to be published once and die a slow death, they should thrive :)

[indutny]

-1 for this.

Things should depricate, otherwise we'll end up with what we've now in browsers. If people decided to migrate to the new stable version of node, they should really do a migration, not just build/install new version.

[jfhbrook]

Just deprecate it. People had months of warnings and we even wrote a bot to fix it for them. All they have to do is click a green button.

[luk-]

-1. I'm also disappointed to see this back in for the reasons @shtylman and @indutny mentioned. I can see why it would be a frustrating change for Joyent but I think it's a good step for node and the community.

[bcantrill]

An important part of becoming a more mature software platform is having empathy with those who use and deploy upon that platform. This is breaking users -- indeed, the early adopters -- over nothing. (I would call this a point of principle, but I honestly don't know what the principle is.) This is -- as Isaac mentioned -- 80% of the complaining about 0.8.0. You may say that "a bot will fix them", but that doesn't fly when your software is enterprise-grade production software. Again, this is stupid -- and (worst of all) it lends credence to some of the stereotypes about node (stereotypes that people like Isaac and I have fought very hard to dispel).

[defunctzombie]

"enterprise-grade production software" what does that even mean?

I think the developers had enough empathy. A version of deprecation and then removal. I think the migration docs are pretty clear on the matter. Yes, we are all busy people.

[jfhbrook]

fwiw this hasn't been much of an issue at nodejitsu outside a few stale cloudhead libraries that we try not to use anyway. Then again, we also test everything out on 0.8 so it won't be a disaster when we offer it in production.

[Sannis]

@bcantrill you can solve this with sys-not-throw and only two lines for each executable instead of replace s/sys/util/ over all your code. But I think it should not be a degradation from deprecated state to module.exports = require('util'); without any warning.

[luk-]

@bcantrill do you think this should ever be removed? How indefinite are you talking about in regard to indefinite future?

I empathize with your comment on working with enterprise-grade stuff, but is a < 1.0 release not a good time to deprecate? I have no idea how 1.0 and beyond releases will be managed and if it will be any different, but now seems like a great time to 'mess' with core modules before the possibility of versioning being more in control of the type of thing.

[isaacs]

"enterprise-grade production software" what does that even mean?

It means "we have a lot of programs running systems that companies are paying a lot of money to use, and which are error-prone and tedious to upgrade". Like, many datacenters, thousands of servers, international partners, etc.

Let's be reasonable about this:

1. What is the cost of keeping "sys" throwing?
2. What is the cost of putting it back?

The cost of 1 is "Increased difficulty of migrating code from 0.6 (or earlier) to 0.8." This is harmful for the project long term. It also results in greater skepticism about migrating from 0.8 to 0.next or 1.0. It injures our credibility when we say, "No, it'll work, trust me."

The cost of 2 is "A user might ask someday, 'Why did you do require('sys') instead of require util?' and you'll have to tell them." They'll get it. That's not a real thing. However, it will perhaps injure our credibility when we say, "XYZ is deprecated. Don't use it. It'll be removed", because people will think, "Yeah, but that's what you said about sys, and that still works."

So, either way, we suffer a reduction in credibility with respect to a specific sort of message. Which message do you think we'll be saying more of in the future?

1. "Please upgrade to this new version, it'll be better, I promise."
2. "Please don't use this feature, it will be removed."

Unless someone can point to a real hazard of making it not throw, this doesn't even seem debatable, really. The arguments against this proposal are basically, "But that's not what we do". And maybe we should rethink what we do, if "what we do" is making it harder for people to use node.

[mmalecki]

I'm very -1 on that. That way, we will end up reverting every compatibility breakage because "people were using it" (or, even better, "enterprise was using it"). sys was supposed to be totally removed in 0.9 (as in, it'd throw Cannot find module). That's the only sane thing we can do right now.

Learn to fix your code. Node is a fast moving project. APIs will break.

Also, as @jesusabdullah said, there's a bot which does that for you. Just put it on GitHub.