CONTRIBUTING.md

[hassankhan]

Contributing

Guidelines

• Coding Standard: Linting errors are checked by ESLint and
  stylistic issues are handled by Prettier. Keeping a
  consistent style throughout the codebase keeps the cognitive load low for all
  contributors and keeps the code style homogeneous.

• Node 8 LTS: serverless-webpack has a minimum Node version
  requirement of 8.0.0. Pull requests must not require a Node version greater
  than that.

• Add tests: All pull requests should include unit tests to ensure the
  change works as expected, to prevent regressions and maintain coverage.

• Document any change in behaviour: Make sure any documentation is kept
  up-to-date.

• Consider our release cycle: We try to follow SemVer v2.
  Randomly breaking public APIs is not an option.

• Use GitHub Flow: Don't ask us to pull from your master branch. Set up
  GitHub Flow and create a new feature branch from master.

• One pull request per feature: If you want to do more than one thing, send
  multiple pull requests.

• Send coherent history: Make sure each individual commit in your pull
  request is meaningful. If you had to make multiple intermediate commits while
  developing, please rebase or squash them before
  submitting.

• Useful commit messages: Commit messages should be short and descriptive.
  If your commit affects existing issues/PRs then use
  GitHub keywords where possible.

Running tests

In order to contribute, you'll need to checkout the source from GitHub and
install dependencies using npm:

git clone https://github.com/serverless-heaven/serverless-webpack.git
npm test

Releasing a new version

Create a new milestone with the intended version number, and assign any relevant
issues and/or pull requests to it. Pull requests should be merged only if all
checks pass and the code coverage thresholds are met. This usually means that
contributors will often have to write tests as part of the submission process.

Reporting a security vulnerability

We want to ensure that serverless-webpack is secure for everyone. If
you've discovered a security vulnerability, we appreciate your help in
disclosing it to us in a responsible manner.

Publicly disclosing a vulnerability can put the entire community at risk. If
you've discovered a security concern, please email us at
[email protected] with [SECURITY] in the subject line. We'll work
with you to make sure that we understand the scope of the issue, and that we
fully address your concern. We consider correspondence sent to this email
address our highest priority, and work to address any issues that arise as
quickly as possible.

After a security vulnerability has been corrected, a security hotfix release
will be deployed as soon as possible.

Happy coding!

[HyperBrain]

install dependencies using Yarn

or npm ;-)

[hassankhan]

Haha good catch, I lifted it straight out of a work project so might've missed a few things 😊

[HyperBrain]

please email us at <SECURITY_EMAIL> with [SECURITY] in the subject line

Does anybody know, if a GitHub team (like us here) can be reached via an email address?

[hassankhan]

Does anybody know, if a GitHub team (like us here) can be reached via an email address?

Not to my knowledge, unfortunately. Some Googling around didn't reveal anything obvious either, so not quite sure what to do 😕

[hassankhan]

The only way I can think of involves registering a domain, which obviously would require someone to bear the cost.

If we were to set the domain up on AWS, we could use SES to create an inbound email address. We could have it forward emails to SNS, and have it forward them to our personal emails.

EDIT: Another upshot of having a domain would be that we could potentially host a documentation site in the future.

[HyperBrain]

I already have registered serverless-heaven for a long time. You're right, I'll just use SES and get some forwarder ready. Regarding the costs, I pay for the domain anyway, so SES should not make a big difference.

…

On Sat, Apr 27, 2019 at 10:46 PM Hassan Khan ***@***.***> wrote: The only way I can think of involves registering a domain, which obviously would require someone to bear the cost. If we were to set the domain up on AWS, we could use SES to create an inbound email address. We could have it forward emails to SNS, and have it forward them to our personal emails. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://github.com/orgs/serverless-heaven/teams/serverless-webpack-team/discussions/7/comments/5>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABKEZXVP5ULM3ST7JNMOASDPSS3ORANCNFSM4HIRIPPQ> .

[hassankhan]

Awesome, could we make the email [email protected]?

[hassankhan]

Also I've just updated the text above with some information about the release process. If everyone is happy with it, I'd like to make it a part of #496.

[HyperBrain]

Awesome, could we make the email [email protected]?

As I plan to move my serverless-aws-alias plugin to heaven too, I'd suggest [email protected]

Under "Guidelines" we should also tell users to add the editorconfig and eslint plugins to their editors. This will help to have clean and correct files.

[hassankhan]

Under "Guidelines" we should also tell users to add the editorconfig and eslint plugins to their editors. This will help to have clean and correct files.

After #496 gets merged, then this would automatically happen as part of the pre-commit hook.

[designfrontier]

Do we want to make that a specific version of node since we are targeting Lambdas which only have 8.10?

[HyperBrain]

Lambdas which only have 8.10

This is only true for AWS. With the plugin we also target other platforms like Azure, Google Functions or OpenWhisk, where the Node version can vary and is not clear. The only thing we can define is a minimum Node version. For me, anything from 8.x should be ok - and it is only for the host/build platform, not the target which can be configured in the webpack config.

[HyperBrain]

@hassankhan

One pull request per feature

Additionally, we should state: "No pull request without a linked issue (ticket)". This allows us to discuss an issue or feature and also discuss the way it should be implemented. PRs without issues should only be provided for trivial things, like documentation fixes, typos or for the release process.