Javascript project standard

[leog]

What is the purpose of this Issue?

• Propose a new Standard

Describe the purpose of this Issue a bit further

I would be really useful to have a common way to write Javascript projects. That would mean that a developer could easily identify certain things about the projects in order to work on it effortlessly.

There are many components to have into account like relying on @feross/standard or its forks which are slightly the same standard with some variations.

As far as how deep this standard should go, the premise is very simple and yet powerful. A standard should just cover what could be verifiable, whether is automatically through a very well supported tool or manually going through any project that asks for validation. For example, it would be very difficult to have verifiable code style guides without any automatic tool, like the one standardjs uses (running standard CLI once it is installed).

Also, a Javascript project is not just only about code style. It's also about certain files that needs to be present to have a very good idea about the project itself. For example, should a JS project have a package.json file (https://docs.npmjs.com/files/package.json) to describe dependencies and other useful information? Should it have a .editorconfig file (http://editorconfig.org) to describe IDE behaviors? Let's get the best practices together to have the best JS projects possible.

I'm just opening the discussion to hopefully get buy-in from other devs to work together towards a better developer experience for all.

[leog]

This is what we've come up with on the company I work for. Please don't hesitate to jump in with more suggestions, concerns, etc.

Required	Description	Subtype
Yes	IDE configuration (.editorconfig recommended): In order to maintain certain level of consistency when developing on any IDE. This is related to the linting point too.	parent
Yes	Linting methods (.eslint recommended): In order to assure certain level of consistency throughout the code.	parent
Yes	A package.json file needs to exist to describe basic information about the project. The mandatory properties are: name, version, main, private, description and repository. The version needs to follow SemVer convention.	parent
No	Code modularization (commonjs via webpack recommended): In order to organize your code and provide a clean way of dependencies throughout the project. It's optional as no every Javascript project needs modularization.	app, library
Yes (3)	Run scripts: In order to prepare the project to be usable to others. If a package.json is present, these scripts should exist depending on the type of project: Required Description Subtype Yes start for starting a node process/server, no build involved. app Yes test to run unit tests (if no test available, configure it to run echo \"Error: no test specified\" && exit 1). parent No build for preparing a client build (webpack build settings recommended). app, library No dev for preparing a client build and watching files for any changes - optionally starts a development server as well, e.g. webpack-dev-server. app, library Yes lint to run linting tools (.eslint recommended). parent	parent
No	Use ES2017 (babel and ES2017 preset recommended): In order to have the best tools to develop Javascript projects with latest effective additions. It's optional as not everyone knows the latest ES standard and not every project needs the latest tools to work effectively.	parent
Yes	Handling dependencies in devDependencies and dependencies depending on whether they are needed for setting up the project environment or the content in the project itself. Both need to be declared using SemVer and not branches but this depends on conventions from the dependency itself Forking a dependency should be very well documented with its purpose and an exit and/or contingency plan for going back to mainstream releases. Use npm shrinkwrap to be sure dependencies won't change	parent