Code Standards and Requirements

For this rewrite, we'd like to keep certain standards and requirements during development in an effort to keep the code as clean as possible. Please follow these guidelines when you are making your contributions. If you have any questions about these guidelines, please contact me.

Contribution Conditions and Expectations

• When you submit a pull request, you agree that your code is published under the GNU General Public License
• Do not introduce non-free software or modules with your code.
• Make sure your pull request is setup to merge your branch to FreeTube's master branch.
• Make sure your branch is up to date with the master branch before submitting your pull request.
• Your pull request should have no linting errors (Run npm run lint to test for problems).
• Stick to a similar style of code already in the project. Please look at current code to get an idea on how to do this.
• Follow ES6 standards in your code. Ex: Use let and const instead of var. Use import instead of require.
• Please add comments to your code when necessary. Follow the JavaScript Documentation and Comments Standard for reference.

Code Standards / Guidelines

• Use the existing code as an example of how your code should be structured. There should be enough in the project already to give you a rough idea on how the rest of the app should be put together.
• Reuse code from the old FreeTube code base when appropriate. This code can also be used as a rough example on what checks need to be made for each feature. If you end up using code from the old code base, feel free to clean it up as you port it over (it will probably need to be cleaned up).
• New Vue components should be structured similarly to existing ones. The /components folder should include folders that each contain only one component. The component should have the template, js, and css separated in their own files for organization purposes.
• When making a feature that involves an API, add functionality to utilize both the Invidious API and a local API if available. The feature should fallback to the other API automatically if a flag is enabled. Any local API included should rely on scraping YouTube instead of using an API key. There are available libraries for most local API functionality that we may need. If you're unsure if one is available, ask.
• Design your code to use as few dependancies on Electron as possible. One stretch goal we'd like to have with the rewrite is to prepare FreeTube for deployment onto servers for remote access. It is not a focused goal but something to keep in mind while creating new features. Add checks for if Electron is available or not when possible.
• Check the issues tab for guidelines and requirements for what feature set I'd like to see in a new feature. These should help out if you get stuck and don't know what to include in a feature. If you need some clarification on a certain feature, the thread is available for discussion. If an issue hasn't been created for something that you'd like to work on, please create one. I can also add requirements for a created issue if you'd like some extra direction when creating it.