├── .github ├── ISSUE_TEMPLATE │ ├── bug_report.md │ ├── other-issue.md │ ├── template-request.md │ └── template-submission.md └── config.yml ├── LICENSE ├── README.md ├── assets └── code-exchange-banner.jpg ├── docs └── QUALITY_CHECKLIST.md └── guidelines ├── NODE_JS.md └── README.md /.github/ISSUE_TEMPLATE/bug_report.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Bug report 3 | about: Create a report to help us improve 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | **Where has this bug occurred?** 11 | Has this bug occurred in one of the templates? If so, please specify the link to the template. If this bug occurred on the website, please link to the part of the website. 12 | 13 | **Describe the bug** 14 | A clear and concise description of what the bug is. 15 | 16 | **To Reproduce** 17 | Steps to reproduce the behavior: 18 | 1. Go to '...' 19 | 2. Click on '....' 20 | 3. Scroll down to '....' 21 | 4. See error 22 | 23 | **Expected behavior** 24 | A clear and concise description of what you expected to happen. 25 | 26 | **Screenshots** 27 | If applicable, add screenshots to help explain your problem. 28 | 29 | **Template bug info (please complete the following information if the bug exists in one of the templates):** 30 | - Template source link: [e.g. github.com/twilio-labs/sample-appointment-reminders-nodejs] 31 | - OS: [e.g. macOS 10.14.6] 32 | - Programming language and version: [e.g. JavaScript, Node.js 12.4, npm 6.8] 33 | 34 | **Desktop (please complete the following information):** 35 | - OS: [e.g. iOS] 36 | - Browser [e.g. chrome, safari] 37 | - Version [e.g. 22] 38 | 39 | **Smartphone (please complete the following information):** 40 | - Device: [e.g. iPhone6] 41 | - OS: [e.g. iOS8.1] 42 | - Browser [e.g. stock browser, safari] 43 | - Version [e.g. 22] 44 | 45 | **Additional context** 46 | Add any other context about the problem here. 47 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/other-issue.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Other issue 3 | about: Please pick this category if you cannot match your issue to another category. 4 | title: '' 5 | labels: '' 6 | assignees: '' 7 | 8 | --- 9 | 10 | 11 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/template-request.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Template Request 3 | about: Request a template for a new or existing use case 4 | title: "[Template Request] " 5 | labels: template-request 6 | assignees: '' 7 | 8 | --- 9 | 10 | **What is your use case? Please describe.** 11 | A clear and concise description of what your use case is. Ex. I'm trying to do [...] when [...] is happening. 12 | 13 | **Describe the solution you'd like** 14 | A clear and concise description of what you want to happen. 15 | 16 | **Specify the preferred programming language/environment:** 17 | [e.g. Node.js or Twilio Functions] 18 | 19 | **Additional requirements/dependencies:** 20 | List any additional requirements this template should fulfill. 21 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/template-submission.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Template Submission 3 | about: Submit a template to be added to the Twilio CodeExchange 4 | title: '[Template Submission]' 5 | labels: template-submission 6 | assignees: 'dkundel' 7 | --- 8 | 9 | **Important**: 10 | Please make sure to first read and sign the agreement at [ahoy.twilio.com/code-exchange-community](https://ahoy.twilio.com/code-exchange-community) before proceeding here. 11 | 12 | **What's the use case for the template?** 13 | Please explain what use case this template is solving. If this is another programming language implementation for an existing use case, please copy the link here. 14 | 15 | **What's the programming language?** 16 | What programming language is primarily used for this template? If there's a front-end and back-end component, please list the back-end language. 17 | 18 | > For any Twilio Function templates please submit them via a pull request to github.com/twilio-labs/function-templates 19 | > [e.g. Node.js] 20 | 21 | **Template GitHub URL:** 22 | Please list the GitHub URL of your project. e.g. github.com/twilio-labs/sample-appointment-reminders-node 23 | 24 | **Author Information (please fill out):** 25 | 26 | - Author name (or organization if submitted on behalf of a company): [e.g. Twilio] 27 | - Author GitHub organization/user: [e.g. github.com/twilio] 28 | - GitHub username you used to sign [the Agreement](https://ahoy.twilio.com/code-exchange-community): [e.g. dkundel] 29 | 30 | **Additional dependencies:** 31 | Please list any external dependencies for services, tools or similar this project has. 32 | 33 | **Checklist:** 34 | 35 | > Please check every part of this checklist for us to process your request. You can do this by marking them with `[x]` instead of `[ ]`. 36 | 37 | - [ ] I've filled out the form at [ahoy.twilio.com/code-exchange-community](https://ahoy.twilio.com/code-exchange-community) 38 | - [ ] My sample application is open source and has a permissive license such as MIT or Apache-2 39 | - [ ] There are no known security vulnerabilities and I'm following security best practices 40 | - [ ] I've read Twilio's [best practices coding guidelines](https://github.com/twilio-labs/code-exchange/tree/master/guidelines) for my project 41 | - [ ] I agree and adhere to the [Code of Conduct](https://github.com/twilio-labs/.github/blob/master/CODE_OF_CONDUCT.md) 42 | - [ ] The template has been authored by me / or my organization and will be kept up-to-date. If the template will not longer be maintained, I'll notify this project. 43 | -------------------------------------------------------------------------------- /.github/config.yml: -------------------------------------------------------------------------------- 1 | newIssueWelcomeComment: | 2 | Thank you so much for opening your first issue in this project! We'll try to get back to it as quickly as possible. 3 | 4 | While you are waiting...here's a random picture of a corgi (powered by [dog.ceo](https://dog.ceo)) 5 | ![picture of dog](https://images.dog.ceo/breeds/corgi-cardigan/n02113186_6608.jpg) 6 | 7 | firstPRMergeComment: > 8 | Congratulations to your first contribution! 9 | 10 | If you are on the look out for more ways to contribute to open-source, 11 | check out a list of some of our repositories at https://github.com/twilio/opensource. 12 | 13 | To stay up-to-date with Twilio open source related updates, sign up here: https://twil.io/oss-updates 14 | 15 | And if you love Twilio as much as we do, make sure to check out our 16 | [Twilio Champions program](https://www.twilio.com/champions)! 17 | 18 | ![picture of a happy corgi looking at the camera](https://images.dog.ceo/breeds/corgi-cardigan/n02113186_4902.jpg) 19 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2020 Twilio Labs 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # ![Twilio Code Exchange](assets/code-exchange-banner.jpg) 2 | 3 | The [Twilio Code Exchange][codeexchange] is a central hub for developers to find sample applications that get them started on solving particular use cases. You can find all samples by visiting the [Twilio Code Exchange page][codeexchange]. 4 | 5 | ## About this repo 6 | 7 | This repository serves a place for you to: 8 | 9 | 1. File bugs with respect to either template applications or the general website 10 | 2. Request new templates for use cases 11 | 3. Submit a request to have your own app added to [Code Exchange][codeexchange] 12 | 4. Learn about the [coding guidelines][guidelines] we use for our respective applications 13 | 5. Give general feedback 14 | 15 | ## Contributing to Code Exchange 16 | 17 | We built [Code Exchange] for the community and want to allow you all to be a part of it. 18 | 19 | There are different ways you can contribute to Code Exchange: 20 | 21 | ### 1. Contribute functionality or fix issues for existing applications 22 | 23 | Every sample you find on [Code Exchange] is open-source and welcomes contributions. Click the `View on GitHub` button on the respective sample and you'll be redirect to the respective repository. 24 | 25 | From there make sure to inspect the `README.md`, `CONTRIBUTING.md` (if available) and any open issues before you get started. 26 | 27 | ### 2. Contribute to Twilio Function templates 28 | 29 | Some of the samples on [Code Exchange] are samples written for [Twilio Functions](https://www.twilio.com/runtime/build) a serverless JavaScript environment that's part of the [Twilio Runtime](https://www.twilio.com/runtime). You can identify these samples by their `Host on Twilio` label. 30 | 31 | All of these samples are hosted in one single repository called [twilio-labs/function-templates](https://github.com/twilio-labs/function-templates). Check out the project's [`CONTRIBUTING.md`](https://github.com/twilio-labs/function-templates/blob/master/docs/CONTRIBUTING.md) for concrete ways to contribute to that project. 32 | 33 | ### 3. Add your own application to Code Exchange 34 | 35 | If you already have an application or are planning to build an application that you'd like us to feature on [Code Exchange], please follow the following steps. 36 | 37 | #### Step 0 [optional]: 38 | 39 | If you haven't yet, this is a good place to start working on your application code. 40 | 41 | #### Step 1: 42 | 43 | Head over to our [Code Exchange Community Program page][community] and review our [Twilio Code Exchange Community Program Agreement][agreement]. Once you've reviewed it, make sure you [fill out our form][community]. 44 | 45 | #### Step 2: 46 | 47 | Take a look at our [coding guidelines][guidelines]. While adhering to every point of them is not mandatory, we'd like you to review them as those are the guidelines we use to develop our own sample applications to create a coherent experience. 48 | 49 | #### Step 3: 50 | 51 | Once you are ready to submit your application, [create a new issue][newissue] and choose `Template Submission`. Fill out the form that is pre-populated and submit your issue. 52 | 53 | After that we'll try to get back to you as soon as possible with any questions we might have or the link to your application on [Code Exchange]. 54 | 55 | ### 4. File issues with existing applications 56 | 57 | As much as contributing code seems to be the most valuable way to contribute to any open-source project, having folks that find bugs, [create issues][newissue] and create detailed steps to replicate the bugs is one of the most crucial parts of open-source development. 58 | 59 | ## Code of Conduct 60 | 61 | Please be aware that every interaction with this project is governed by our [Code of Conduct][coc]. 62 | 63 | ## License 64 | 65 | This project and the guidelines are released under the following license: 66 | 67 | MIT 68 | 69 | [coc]: https://github.com/twilio-labs/.github/blob/master/CODE_OF_CONDUCT.md 70 | [newissue]: https://github.com/twilio-labs/code-exchange/issues/new/choose 71 | [guidelines]: guidelines/ 72 | [community]: https://ahoy.twilio.com/code-exchange-community 73 | [agreement]: https://ahoy.twilio.com/twilio-codeexchange-community-program-agreement 74 | [codeexchange]: https://www.twilio.com/code-exchange 75 | -------------------------------------------------------------------------------- /assets/code-exchange-banner.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/twilio-labs/code-exchange/a8e7f3219aa75d919143daa104c320334f5d0553/assets/code-exchange-banner.jpg -------------------------------------------------------------------------------- /docs/QUALITY_CHECKLIST.md: -------------------------------------------------------------------------------- 1 | The purpose of this checklist is to assess the state of this repository, and bring it to an acceptable level for long-term support by completing the tasks listed below. 2 | 3 | **This checklist is used internally but can be used as a guidance for others** 4 | 5 | > Please check every part of this checklist for us to process your request. You can do this by marking them with [x] instead of [ ]. 6 | 7 | ### Documentation 8 | 9 | - [ ] `LICENSE` file exists in repository 10 | 11 | - [ ] [Code of Conduct](https://github.com/twilio-labs/.github/blob/master/CODE_OF_CONDUCT.md) exists in repository 12 | 13 | - [ ] [CONTRIBUTING](https://github.com/twilio-labs/.github/blob/master/CONTRIBUTING.md) exists in repository 14 | 15 | - [ ] No broken links in README.md 16 | 17 | - [ ] Build status exists at top of README.md 18 | 19 | - [ ] Set up steps are complete and accurate 20 | 21 | - [ ] CodeExchange repository is linked in README.md 22 | 23 | ### GitHub 24 | 25 | - [ ] Dependabot set up 26 | 27 | - [ ] Dependabot automerge set up 28 | 29 | - [ ] Uses GitHub Actions (required for Twilio sample) or other CI 30 | 31 | ### Code 32 | 33 | - [ ] Packages/dependencies are up to date 34 | 35 | - [ ] Code compiles against latest packages/dependencies 36 | 37 | - [ ] Matches [CodeExchange Guidelines](https://github.com/twilio-labs/code-exchange/tree/master/guidelines) to the best of ability 38 | 39 | ### Tests 40 | 41 | - [ ] Functionality tests have been created 42 | 43 | - [ ] All tests pass 44 | 45 | ### App 46 | 47 | - [ ] Confirmed sample behaves as expected (after dependencies have been updated) 48 | 49 | - [ ] This file has been copied into a wiki entry for the respective repository or added as a GitHub issue 50 | 51 | ### General 52 | 53 | - [ ] App is released under a permissive license like MIT or Apache-2 54 | 55 | - [ ] I've read and followed the contribution guidelines 56 | 57 | - [ ] I've read and implemented my template according to the respective coding guidelines for my project 58 | 59 | - [ ] I agree and adhere to the Code of Conduct 60 | 61 | - [ ] The template has been authored by me / or my organization and will be kept up-to-date. If the template will not longer be maintained, I'll notify this project. 62 | -------------------------------------------------------------------------------- /guidelines/NODE_JS.md: -------------------------------------------------------------------------------- 1 | # Node.js Coding Guidelines 2 | 3 | ## Background 4 | 5 | These guidelines have been authored with the following things in mind: 6 | 7 | **consistency** 8 | All code should be formatted and written the same way 9 | 10 | **maintainability** 11 | Having automated tests to check the main functionality of the application allows us to keep apps up-to-date 12 | 13 | **pluggability** 14 | By keeping a consistent application format and a minimum consistent set of dependencies means developer can more easily combine different applications 15 | 16 | **contribution-friendliness** 17 | Every template/application should be friendly to new contirbutors to allow to fix bugs or add missing features. 18 | 19 | ## Guidelines 20 | 21 | With these criteria in mind we came up with the following guidelines. To make it easy for people to get started, we are also maintaining an example repository that you can use as a template for your application: 22 | ==> github.com/twilio-labs/sample-template-nodejs 23 | 24 | **If possible use the [provided template to start your application](https://github.com/twilio-labs/sample-template-nodejs).** 25 | 26 | ### 1. Be familiar 27 | 28 | Any of our applications should feel familiar to the developer. While for a general Node.js application that might mean we can start with a blank slate application, for some applications like a React app this means starting with the standard bootstrapped project. For example using `create-react-app` for React, `ng init` for Angular, etc. 29 | 30 | After that see how the remaining guidelines fit into this. 31 | 32 | ### 2. Use a linter 33 | 34 | Linting allows us to keep the code consistent. The preferred linter for us is a combination of [`eslint`](https://npm.im/eslint) and [`prettier`](https://npm.im/prettier). 35 | 36 | The preferred configurations for these tools are: 37 | 38 | - [`.eslintrc.json`](https://github.com/twilio-labs/sample-template-nodejs/blob/master/.eslintrc.json) 39 | - [`.prettierrc`](https://github.com/twilio-labs/sample-template-nodejs/blob/master/.prettierrc) 40 | 41 | ### 3. Testing 42 | 43 | Our code should be reliable and maintainable and testing plays a big part in this. The more tests you can author for your application, the better. However, at the very least you should have some general tests covering the core functionality of your application. This will allow us to keep applications easier up-to-date with automated dependency updates. 44 | 45 | Our preferred testing frameworks are: 46 | 47 | - [`jest`](https://jestjs.io/) as a general testing framework (backend & frontend) 48 | - [`cypress`](https://www.cypress.io/) for E2E UI tests 49 | - [`mocha`](https://npm.im/mocha) and [`chai`](https://npm.im/chai) if already available in the project 50 | - [`supertest`](https://npm.im/supertest) for testing HTTP APIs 51 | - [`nock`](https://npm.im/nock) for mocking external APIs like Twilio 52 | 53 | When in doubt you should cover tests for template applications in the following order: 54 | 55 | 1. Test the endpoints/webhooks your app is exposing (for example using `supertest`) 56 | 2. Create E2E tests for your user interface to check for the basic functionality 57 | 3. Write additional unit tests starting with the mosts complex/critical functions 58 | 59 | ### 4. Frameworks & libraries 60 | 61 | In general you should use as many or little libraries as it makes sense for the respective target audience. Less libraries and dependencies makes it easier for people to adopt it. But if that means the codebase increases significantly because of code that is seemingly unrelated to the use-case, use a library/dependency instead. 62 | 63 | If an application can be written in a serverless & stateless fashion like using [Twilio Functions](https://twilio.com/functions), you should prefer that, write your template as a Function Template and submit it to github.com/twilio-labs/function-templates. 64 | 65 | If you'll require a more complex webserver, use [`express`](https://npm.im/express) as for scaffolding your webserver. 66 | 67 | Some other common libraries and tools that can be used in your template: 68 | 69 | - [`nodemon`](https://npm.im/nodemon) for restarting development servers 70 | - [`got`](https://npm.im/got) for HTTP requests in Node.js 71 | - [`parcel-bundler`](https://parceljs.org/getting_started.html) for a general purpose bundler unless [`webpack`] is already part of the project. `parcel` supports a wide variety of functionality without any configuration necessary 72 | - [`node-env-run`](https://npm.im/node-env-run) and [`configure-env`](https://npm.im/configure-env) as libraries for loading and setting environment variables (see next section). Alternatively [`dotenv`](https://npm.im/dotenv) or [`dotenv-safe`](https://npm.im/dotenv-safe) 73 | 74 | ### 5. Using Environment Variables 75 | 76 | Credentials for Twilio and other external services as well as things like service SIDs should be stored as environment variables. In order to make it easy for people to get started, every project should use `.env` files for this. 77 | 78 | The actual `.env` file should never be included in a template and should be part of the `.gitignore` file. However, a project should have an `.env.example` file that specifies every environment variable necessary, including default values where applicable and a comment line (prefixed with `#`) above it specifying what this value is and how to retrieve the value (for example sign up at twilio.com). 79 | 80 | The tool [`configure-env`](https://npm.im/configure-env) can be used in a setup script or in the setup instructions and will use the `.env.example` file as a fundation to prompt the user for these values 81 | 82 | Libraries to load environment variables are: 83 | 84 | - [`node-env-run`](https://npm.im/node-env-run) to run Node with values from a `.env` file without having to modify code 85 | - [`dotenv-safe`](https://npm.im/dotenv-safe) to load env variables and check if everything in `.env.example` is also set in `.env` 86 | - [`dotenv`](https://npm.im/dotenv) to just load `.env` files 87 | 88 | ### 6. Databases 89 | 90 | We want to make the project setup for people as easy as possible. In order to avoid them having to wrestle with databases, whenever possible, you should use a filesystem based one. For basic use cases [`lowdb`](https://npm.im/lowdb) is a good library. For more advanced use cases [`sqlite3`](https://github.com/mapbox/node-sqlite3) can come handy. 91 | 92 | If possible you should also pre-populate the database with some basic data. 93 | 94 | ### 7. Continous Integration 95 | 96 | GitHub introduced GitHub Actions as a way to run continous integration tests directly on their platform allowing to test apps on Windows, Linux and macOS. This is our preferred way of running tests and other automation. You can find some basic templates in the sample repository: https://github.com/twilio-labs/sample-template-nodejs/tree/master/.github/workflows 97 | 98 | ### 8. General Files & Structure 99 | 100 | Every project should have the following files to improve the experience for developers: 101 | 102 | - `README.md` with a [structure following the template project](https://github.com/twilio-labs/sample-template-nodejs/blob/master/README.md) 103 | - `CONTRIBUTING.md` explaining how to contribute to this project for example to fix bugs. This can be included in the `README.md` 104 | 105 | As for the overall structure of your project, follow what's the best practice for the target audience. For a general Node.js application, take the basic template as a reference: https://github.com/twilio-labs/sample-template-nodejs 106 | -------------------------------------------------------------------------------- /guidelines/README.md: -------------------------------------------------------------------------------- 1 | # Template Application Coding Guidelines 2 | 3 | ## Background 4 | 5 | These guidelines have been authored with the following things in mind: 6 | 7 | **consistency** 8 | All code should be formatted and written the same way 9 | 10 | **maintainability** 11 | Having automated tests to check the main functionality of the application allows us to keep apps up-to-date 12 | 13 | **pluggability** 14 | By keeping a consistent application format and a minimum consistent set of dependencies means developer can more easily combine different applications 15 | 16 | **contribution-friendliness** 17 | Every template/application should be friendly to new contirbutors to allow to fix bugs or add missing features. 18 | 19 | ## Guidelines 20 | 21 | With these criteria in mind we came up with the following guidelines. These guidelines have also been used to create the following repository templates that you can use to bootstrap your project: 22 | 23 | - [sample-template-nodejs](https://github.com/twilio-labs/sample-template-nodejs) 24 | 25 | ### 1. Be familiar 26 | 27 | Any of our applications should feel familiar to the developer. While for a general Node.js application that might mean we can start with a blank slate application, for some applications like a React app this means starting with the standard bootstrapped project. For example using `create-react-app` for React, `ng init` for Angular, etc. 28 | 29 | After that see how the remaining guidelines fit into this. 30 | 31 | ### 2. Use a linter 32 | 33 | Linting allows us to keep the code consistent. The rules themselves are less important than the actual presence of a linter as long as there's the capaibility to "auto fix" or proper guides that make it easy for new developers to adhere to the linter rules. 34 | 35 | ### 3. Testing 36 | 37 | Our code should be reliable and maintainable and testing plays a big part in this. The more tests you can author for your application, the better. However, at the very least you should have some general tests covering the core functionality of your application. This will allow us to keep applications easier up-to-date with automated dependency updates. 38 | 39 | When in doubt you should cover tests for template applications in the following order: 40 | 41 | 1. Test the endpoints/webhooks your app is exposing 42 | 2. Create E2E tests for your user interface to check for the basic functionality 43 | 3. Write additional unit tests starting with the mosts complex/critical functions 44 | 45 | ### 4. Frameworks & libraries 46 | 47 | In general you should use as many or little libraries as it makes sense for the respective target audience. Less libraries and dependencies makes it easier for people to adopt it. But if that means the codebase increases significantly because of code that is seemingly unrelated to the use-case, use a library/dependency instead. 48 | 49 | If an application can be written in a serverless & stateless fashion like using [Twilio Functions](https://twilio.com/functions), you should prefer that, write your template as a Function Template and submit it to github.com/twilio-labs/function-templates. 50 | 51 | ### 5. Using Environment Variables 52 | 53 | Credentials for Twilio and other external services as well as things like service SIDs should be stored as environment variables. In order to make it easy for people to get started, every project should use `.env` files for this. 54 | 55 | The actual `.env` file should never be included in a template and should be part of the `.gitignore` file. However, a project should have an `.env.example` file that specifies every environment variable necessary, including default values where applicable and a comment line (prefixed with `#`) above it specifying what this value is and how to retrieve the value (for example sign up at twilio.com). 56 | 57 | The tool [`configure-env`](https://npm.im/configure-env) can be used in a setup script or in the setup instructions and will use the `.env.example` file as a fundation to prompt the user for these values 58 | 59 | Most programming languages offer libraries that help working with `.env` files. 60 | 61 | ### 6. Databases 62 | 63 | We want to make the project setup for people as easy as possible. In order to avoid them having to wrestle with databases, whenever possible, you should use a filesystem based one. One database that works with a variety of programming languages is SQLite3 64 | 65 | If possible you should also pre-populate the database with some basic data. 66 | 67 | ### 7. Continous Integration 68 | 69 | GitHub introduced GitHub Actions as a way to run continous integration tests directly on their platform allowing to test apps on Windows, Linux and macOS. This is our preferred way of running tests and other automation. You can find some basic templates in the sample repository: https://github.com/twilio-labs/sample-template-nodejs/tree/master/.github/workflows 70 | 71 | ### 8. General Files & Structure 72 | 73 | Every project should have the following files to improve the experience for developers: 74 | 75 | - `README.md` with a [structure following the template project](https://github.com/twilio-labs/sample-template-nodejs/blob/master/README.md) 76 | - `CONTRIBUTING.md` explaining how to contribute to this project for example to fix bugs. This can be included in the `README.md` 77 | 78 | As for the overall structure of your project, follow what's the best practice for the target audience. 79 | 80 | For a general applications, take a look at the available templates listed further up. 81 | 82 | ## Language specific guidelines 83 | 84 | In addition to the general guidelines we also started creating language specific guidelines: 85 | 86 | - [Node.js](NODE_JS.md) 87 | 88 | > Can't find your programming language? We are slowly adding more programming languages to the guidelines. If you'd like to contribute, feel free to create an issue and let us know how you'd like to contribute. 89 | --------------------------------------------------------------------------------