Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion] Provide an environment which allows NestJS to break its public API #1145

Closed
BrunnerLivio opened this issue Oct 2, 2018 · 4 comments

Comments

@BrunnerLivio
Copy link
Member

BrunnerLivio commented Oct 2, 2018

I'm submitting a...


[ ] Regression 
[ ] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.
[x] Other

Context

Angular breaks it's public API a lot (~each 5 months). But it is still quite comfortable to upgrade. With Nest we should achieve the same environment.

What is the motivation / use case for changing the behavior?

When I tried to upgrade my application some bugs occurred, which were not mentioned in the migration guide. Quite frankly I had edge cases (e.g. inject configuration outside context #678), but still as a user I should be able to expect my application still works fine when I follow the migration guide.

Discussion

We should discuss how we can create a development environment, so the user can upgrade his/her application easily.

What does it actually mean to provide such an environment?

  • Add e2e tests for edge cases such as dynamic Modules metadata does not support circular structures #678 . Not just fix the reported bug, but also add an overall test so the issue is less likely to occur in future releases
  • Add integration tests, so we can assure every module from the Nest org still works in future releases
  • Add a migration website like update.angular.io
  • Add nest update command for the NestJS CLI
  • Document changelogs, also for minor releases. (changelog.md file -> Generate into HTML and include into docs)

We can break the named points down into issues later on, but first we should just summarize / brainstorm / discuss.

Please comment if some additional points come to your mind

@BrunnerLivio BrunnerLivio changed the title [Discussion] Provide a better environment to make breaking changes more comfortable for the user [Discussion] Provide an environment which allows NestJS to break its public API Oct 2, 2018
@marcus-sa
Copy link

Not wanting to upgrade just because you're afraid to break the public API is stupid.
+1

@BrunnerLivio
Copy link
Member Author

BrunnerLivio commented Oct 2, 2018

Thinking about this issue; I think this discussion will lead to nothing respectively the named points should be confronted differently. I'll close this issue because of that

@kamilmysliwiec
Copy link
Member

kamilmysliwiec commented Oct 2, 2018

Thinking about this issue; I think this discussion will lead to nothing respectively the named points should be confronted differently. I'll close this issue because of that

Agree.

Nevertheless, agree on all following things as well:

  1. Add e2e tests for edge cases such as dynamic Modules metadata does not support circular structures #678 . Not just fix the reported bug, but also add an overall test so the issue is less likely to occur in future releases
  2. Add integration tests, so we can assure every module from the Nest org still works in future releases
  3. Add a migration website like update.angular.io
  4. Add nest update command for the NestJS CLI
  5. Document changelogs, also for minor releases. (changelog.md file -> Generate into HTML and include into docs)

Let's focus on 1, 2, and 5 for now. 3 & 4 should be tracked as separated feature requests/issues 🔥

@lock
Copy link

lock bot commented Sep 24, 2019

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

@lock lock bot locked as resolved and limited conversation to collaborators Sep 24, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants