3.0.1 is a breaking change

[Daniel15]

See yarnpkg/yarn#2072

Version 3.0.1 should probably really be 3.1 as it changes the public API by renaming a file. This is not a patch release as per semver.

[broofa]

I'll let @defunctzombie weigh in on this, but IMHO (and the opinion of everyone in my office I just surveyed) files are not part of the programming interface. Static structure != dynamic behavior. "API" refers to the latter, not the former.

[navels]

certainly. but forgetting about the file structure, this worked in 3.0.0:

const uuid = require('uuid');

and now it does not.

[defunctzombie]

Might be because main got deleted from package file. We need to put that back. The standard require form should continue to work and it was not intent to break that.

…

On Wed, Nov 30, 2016 at 3:15 PM navels ***@***.***> wrote: certainly. but forgetting about the file structure, this worked in 3.0.0: const uuid = require('uuid'); and now it does not. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#163 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFLOH6veO_LFEF99xHHbYMW9ZNJaBW2ks5rDgOHgaJpZM4LAgtC> .

[broofa]

Uh... that still works. Doesn't it?

kieffer@Roberts-MacBook-Pro$ npm install uuid
/Users/kieffer/work
`-- uuid@3.0.1

kieffer@Roberts-MacBook-Pro$ npm show uuid | grep version
  versions:
  version: '3.0.1',

kieffer@Roberts-MacBook-Pro$ node
> const uuid = require('uuid');
undefined
> uuid()
'53fcdf40-095f-4d82-b30c-a613884c69c4'

[broofa]

Also, node documents that {module}/index.js is part of the baseline module loading logic. See Step #2 under LOAD_AS_DIRECTORY, per https://nodejs.org/api/modules.html#modules_all_together

So... what exactly are we doing wrong here? I get that providing a main field in package.json might be a useful hint, but it's certainly not required... right?

[navels]

See yarnpkg/yarn#2072.

I'm not sure why your repro succeeds and our builds are failing. My workaround is to shrinkwrap our yarn installation so that we pull in uuid 3.0.0.

. . . time passes . . .

What's more, I can no longer reproduce our build failure using 3.0.1. Maybe we just blame it on cache.

[defunctzombie]

@broofa Agreed with your assessment. In my experience index.js is picked up as the canonical entry point for the module when no other main is specified. It is possible that someone had require('uuid/uuid.js'); and our changes would indeed break that. We can certainly move the index file back or symlink or just copy it and publish 3.0.2 to resolve these random issues.

On a related note, I personally don't have much sympathy for packages broken because they used ~ or ^ in their version specifiers for dependencies which I consider worse than an anti-pattern for node modules but that aside, we should still be good module citizens and make this simple fix on our end to ease the pain of those that have not yet learned the right lessons ;)

[Daniel15]

Hmm interesting, I wonder if something else caused yarnpkg/yarn#2072 then. Do you have any ideas?

I personally don't have much sympathy for packages broken because they used ~ or ^ in their version specifiers for dependencies which I consider worse than an anti-pattern for node modules

~ is fine as it just allows upgrading the patch version. Patch releases are always supposed to be API/ABI compatible. Anything larger than small bug fixes should be a minor release (0.x.0). Moving stuff around does not constitute a bugfix 😛 . I agree that ^ is an anti-pattern though.

Having said that, this is one of the major reasons for using Yarn rather than npm - It enforces the usage of a lockfile, which locks in the version numbers of all packages including transitive dependencies. With npm you can use shrinkwrap but it's not as flexible.

[defunctzombie]

~ is fine as it just allows upgrading the patch version. Patch releases are always supposed to be API/ABI compatible.

Compatible with API/ABI doesn't actually mean bug compatible. Often engineering is done not just to the interfaces but to the actual observed behavior provided by those interfaces and when that changes even in the slightest (which can happen with dynamic languages with even just a change from == to === then the entire assumptions previously made may be invalidated.

[navels]

The failure in this case was in the request package used by yarn. Its package.json declares

"uuid": "^3.0.0"

and it fails with

no such file or directory, open '...some...path...here...\node_modules\uuid\uuid.js'

at this line in auth.js:

uuid = require('uuid')

I'm now back to being able to reproduce the error, but not by running node interactively. Will keep digging...

[navels]

Maybe we just blame it on cache.

Indeed, appears to have been a caching problem :)

[defunctzombie]

I am going to close this. Yes, 3.0.1 is by some definition a breaking change but not for anyone who used our documented require('uuid') which is all we have ever supported up to now. Yes you could do require('uuid/uuid.js') but no documentation said this nor did we intend to support it, it is just a by product of being able to require any file by referencing it relative to module root. In this same way many changes can be said to be breaking. Closing this issue until specific details are provided on a documented approach no longer working.