This document should rather be called:
"Some practices for JavaScript projects that work for devs at Hive but might not necessarily work for you."
The use of TC39 proposals IN PRODUCTION. The authors of that document aren't serious.
I figured the string was German.
This way I can develop standards for my team, which as of now really doesn't have any.
I wouldn't adopt more process overhead without a specific reason.
E.g. if you are having quality issues where R&D is shipping stuff before it's ready, then institute a more formal process of sign-off for a release so R&D needs approval from QA.
If you are having problems making builds repeatable, then start standardizing the environments with golden images, put everything in version control, etc.
If you have issues with licenses for third party code, a 3PP (Third party program) process with sign off from legal/other teams (security would be nice).
For each set of problems, there are processes designed to address those. You will also encounter less resistance when the process is a solution to a problem rather than adherence to a best practice. I also wouldn't try to adopt processes just to satisfy a general desire for more process, because there are costs to adopting process overhead, especially the cost of becoming a bit dumber, as an organization, each time you adopt a process to formalize what was previously a judgement call by some decision maker.
I don't want to discourage any company from setting and documenting coding standards, but this particular document feels a bit rushed and could use adherence to best practices of its own. For example,
1. If making an opinionated mandate, provide a link to an explanation
2. Consistently provide links to examples
3. Maybe do some spell-checking: "Hallo"?
4. Try to maintain a uniform level of specificity
E.g. in the section on URL security, there is this vague comment: "Attackers can tamper with any part of an HTTP request, including the URL, query string,"
Which, while a true, doesn't describe what the programmer should or shouldn't do. It's just hanging there. Compare with the weird specificity of listing git commands in section 1.
That tells me the author knew a lot about checking stuff into git, but was a bit out of his/her league when it came to Security, so they just made generic security statements while giving precise instructions for using git.