Class-transformer: fix: 0.3.2 introduced breaking changes on a patch version

Created on 14 Jan 2021  路  7Comments  路  Source: typestack/class-transformer

Description

Minimal code-snippet showcasing the problem

package.json with:

  "dependencies": {
    ...
    "class-transformer": "0.3.1",
  }

Works as expected.


package.json with:

  "dependencies": {
    ...
    "class-transformer": "^0.3.1",
  }

results in:

node_modules/@nestjsx/crud-typeorm/lib/typeorm-crud.service.d.ts:3:27 - error TS2307: Cannot find module 'class-transformer/ClassTransformer' or its corresponding type declarations.

3 import { ClassType } from 'class-transformer/ClassTransformer';
                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Found 1 error(s).

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] build: `nest build`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/runner/.npm/_logs/2021-01-14T11_22_36_530Z-debug.log
Error: Process completed with exit code 1.

Expected behavior

  • This package is versioned as v0 implying breaking changes, so perhaps the behavior is as expected and the issue can be closed 馃槃
  • However given that the package seems to be in use in production by other large packages the expected behavior would be for the package to follow NPM's Semver and include a major version bump for breaking changes.

Actual behavior

  • Package introduced breaking changes on a patch release. (Yes I know pre v1, all good if as intended)
cannot reproduce fix

Most helpful comment

Do you know that when you simply install ^0.3.0 that you AUTOMATICALLY get 0.3.2???

So a computer will NOT read the README.md and will AUTOMATICALLY install the breaking changes

The same will happen with ~0.3.0 ... Sorry about the caps BUT YOU ARE BREAKING production code for people who do NOT lock down dependencies (removing ~ and ^).

but we already released it. It's done.

No, not true. NPM thought of this. You can release version 0.3.3 that reverts the breaking changes AND THEN release a new version called 0.4.0.... Please take seriously

All 7 comments

The issue in @nestjsx/crud-typeorm seems to have been fixed by 1f33bf2f5ec4429dec80481794fd8624b20529c2. Thanks for the speedy fix!

I don't understand, your linked commit is a documentation change only, and not related to the import issues related to ClassType in your example.

Anyway, I am happy your issue is solved. Happy coding!

I predict this issue will cause people many more issue due to breaking changes in PATCH version. I am here because of it...

A new PATCH as 0.3.3 should be released AND THEN the breaking changes can be introduced in 0.4.0

I lost hours to this. Please save someone else

I really don't understand your point. I agree with you that this should be 0.4.0, but we already released it. It's done.

I lost hours to this. Please save someone else

The breaking change is clearly mentioned in the changelog. If someone doesn't read the changelog I cannot help that.

Do you know that when you simply install ^0.3.0 that you AUTOMATICALLY get 0.3.2???

So a computer will NOT read the README.md and will AUTOMATICALLY install the breaking changes

The same will happen with ~0.3.0 ... Sorry about the caps BUT YOU ARE BREAKING production code for people who do NOT lock down dependencies (removing ~ and ^).

but we already released it. It's done.

No, not true. NPM thought of this. You can release version 0.3.3 that reverts the breaking changes AND THEN release a new version called 0.4.0.... Please take seriously

I don't understand, your linked commit is a documentation change only, and not related to the import issues related to ClassType in your example.

I know it is just the README, I am assuming that another library maintainer which we depend on must have seen the change to the README and fixed their package to align to support the breaking changes. The ClassType issue was just the final error message from the TypeScript compiler, and it was just complaining because the method signature had changed. Alternatively me forcing the version to 0.3.1 in our package.json has done the trick.

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

NathanHazout picture NathanHazout  路  5Comments

rmindel picture rmindel  路  5Comments

ERPedersen picture ERPedersen  路  4Comments

leon19 picture leon19  路  5Comments

lazarljubenovic picture lazarljubenovic  路  6Comments