search

kleydon / prisma-session-store

Express session store for Prisma
MIT License
116 stars 18 forks source link

Feature Request: Standardize Contribution #13

Closed wSedlacek closed 3 years ago

wSedlacek commented 3 years ago

I have opened this issue for us to discuss how to make it easier for others to contribute and easier for maintainers to manage those contributions

wSedlacek commented 3 years ago

So with the new TypeScript codebase being completely refactored, it should make future PRs much smaller in scope.

The refactor also introduced linting and 100% test coverage. I believe it would greatly simplify things if CI/CD could be added to run the linting and testing on all PRs via GitHub Actions or a similar solution. This would show any reviewer if everything is passing so they can quickly know if the code can be trusted.

I would also like to add commit linting (via husky) and setup commitizen so that the Conventional Commits pattern can be enforced as easy to use. This pattern would allow us to setup something like semantic-release to automatically generate change logs version the package.

Documentation for contributing would also need to be added.

I believe with these tools the code can remain very high quality with only the need to review and merge PRs on the part of the maintainers.

kleydon commented 3 years ago

Interesting! Hadn't encountered Conventional Commits before... (Now I understand why your commits begin with "feat:", etc...)

I can see how these measures would facilitate collaboration; particularly for any new collaborators ramping up and trying to make sense of the project history.

Would adoption of Conventional Commits result in version numbers automatically bumping up, based on commit content?

Would you envision publishing to npm as an automated aspect of CI/CD, or something reserved as a manual decision?

This level of "professionalization" of a project repo is somewhat new to me. Glad for the chance to benefit from your knowledge here, and begin forming a coherent perspective.

wSedlacek commented 3 years ago

Would adoption of Conventional Commits result in version numbers automatically bumping up, based on commit content?

If you use a tool like semantic-release then yes they would.

Would you envision publishing to npm as an automated aspect of CI/CD, or something reserved as a manual decision?

I would argue that master should always be what is published so this would be an automated part of merging a PR.

kleydon commented 3 years ago

Would adoption of Conventional Commits result in version numbers automatically bumping up, based on commit content?

If you use a tool like semantic-release then yes they would.

Would you envision publishing to npm as an automated aspect of CI/CD, or something reserved as a manual decision?

I would argue that master should always be what is published so this would be an automated part of merging a PR.

Its a little hard for me to envision what the "worst case" might be for this degree of streamlining - but easy to imagine the average/best case scenarios being delightful to use!

I'll defer to your sense for what's best here.

wSedlacek commented 3 years ago

Would adoption of Conventional Commits result in version numbers automatically bumping up, based on commit content?

If you use a tool like semantic-release then yes they would.

Would you envision publishing to npm as an automated aspect of CI/CD, or something reserved as a manual decision?

I would argue that master should always be what is published so this would be an automated part of merging a PR.

Its a little hard for me to envision what the "worst case" might be for this degree of streamlining - but easy to imagine the average/best case scenarios being delightful to use!

I'll defer to your sense for what's best here.

I will create a PR to setup CI/CD and we will go from there.

kleydon commented 3 years ago

👍

kleydon commented 3 years ago

:tada: This issue has been resolved in version 1.1.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket: