Skip to content

Commit

Permalink
Bump version 1.0.3 -> 1.0.4
Browse files Browse the repository at this point in the history 
This new version updates to React 0.14. While I was at it, I adjusted
the changelog to be more accurate.
  • Loading branch information
@lencioni
lencioni committed Oct 13, 2015
1 parent b3e0e9b commit f4dd669
Show file tree
Hide file tree
Showing 2 changed files with 3 additions and 5 deletions.
6 changes: 2 additions & 4 deletions CHANGELOG.md
View file
Original file line number Diff line number Diff line change
@@ -1,8 +1,6 @@
## master (unreleased)
## 1.0.4

- Upgrade for use with React 0.14
- List `react` and `react-dom` as `dependencies` instead of `peerDependency`,
for NPM3 compatibility.
- Bump `react` dependency to 0.14 and add `react-dom` to `peerDependencies`

## 1.0.3

Expand Down
2 changes: 1 addition & 1 deletion package.json
View file
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "react-waypoint",
"version": "1.0.3",
"version": "1.0.4",
"description": "A React component to execute a function whenever you scroll to an element.",
"main": "build/npm/waypoint.js",
"repository": {
Expand Down

5 comments on commit f4dd669

@jatwork
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's a good idea to bump dependencies in a patch commit. This just break my code as we're still using [email protected]. I would rather suggest:

  • unpublish 1.0.4 from npm so it doesn't accidentally breaks any projects.
  • bump to 2.0.0 for this change.

Thanks for the great project! 👍

@lencioni
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah interesting. I apologize for breaking your code, that was not my intention. I was following this advice from semver.org:

What should I do if I update my own dependencies without changing the public API?

That would be considered compatible since it does not affect the public API. Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts. Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality. I would usually expect additional code for the latter instance, in which case it's obviously a minor level increment.

I would have expected npm to prevent you from upgrading this package or show you a warning if the peerDependencies weren't properly met, but perhaps I am misunderstanding how that works. Can you help me understand what steps you took that led to the code breakage?

@remarkablemark
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This broke my project as well.

On my local machine I was already using [email protected] so everything was working fine. But when my project was deployed to a test server, the project broke because a fresh npm install was performed.

If you are curious, the errors are the following:

npm WARN EPEERINVALID [email protected] requires a peer of react@^0.14.0 but none was installed.
npm WARN EPEERINVALID [email protected] requires a peer of react-dom@^0.14.0 but none was installed.

I personally feel that an upgrade from React 0.13.x to 0.14.x should be at least a minor bump. However this may still not be enough because if one installs an npm package with the save flag, the package version is prefixed with a ^ symbol by default, which means that a minor bump will still break many projects that depend on [email protected].

@lencioni
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@remarkablemark Indeed--depending on how people have specified the version in their package.json files, no amount of version bumping will necessarily be "safe". Is there any reason you are not using npm shrinkwrap or checking in your dependencies? This would allow you to navigate the error messages you mentioned in development.

https://nodejs.org/en/blog/npm/managing-node-js-dependencies-with-shrinkwrap/

@remarkablemark
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have been using the ~ instead of the ^ so I get the patch updates for my project but you are right about using npm shrinkwrap for production. Thanks for the reply.

Please sign in to comment.