fmt

.github/ISSUE_TEMPLATE.md

@@ -1,3 +1,4 @@
-- [ ] Have you checked the guidelines in our [Contributing](https://github.com/locutusjs/locutus/blob/main/CONTRIBUTING.md) document?
+- [ ] Have you checked the guidelines in our
+      [Contributing](https://github.com/locutusjs/locutus/blob/main/CONTRIBUTING.md) document?
 
 ### Description

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,4 +1,6 @@
-- [ ] Have you followed the guidelines in our [Contributing](https://github.com/locutusjs/locutus/blob/main/CONTRIBUTING.md) document?
-- [ ] Have you checked to ensure there aren't other open [Pull Requests](https://github.com/locutusjs/locutus/pulls) for the same update/change?
+- [ ] Have you followed the guidelines in our
+      [Contributing](https://github.com/locutusjs/locutus/blob/main/CONTRIBUTING.md) document?
+- [ ] Have you checked to ensure there aren't other open [Pull Requests](https://github.com/locutusjs/locutus/pulls) for
+      the same update/change?
 
 ### Description

CHANGELOG.md

@@ -2,26 +2,33 @@
 
 Our combined changelog and roadmap. It contains todos as well as dones.
 
-Only project-wide changes are mentioned here. For individual function changelogs, please refer to their
-respective Git histories.
+Only project-wide changes are mentioned here. For individual function changelogs, please refer to their respective Git
+histories.
 
-Locutus does not follow SemVer as we're a work in progress - and even though we try,
-we cannot guarantee BC-safety for the hundreds of contributions across the many
-languages that Locutus is assimilating.
+Locutus does not follow SemVer as we're a work in progress - and even though we try, we cannot guarantee BC-safety for
+the hundreds of contributions across the many languages that Locutus is assimilating.
 
-Instead, we recommend using version pinning, and inspect changes for the few particular functions you rely on
-when you upgrade.
+Instead, we recommend using version pinning, and inspect changes for the few particular functions you rely on when you
+upgrade.
 
 ## Backlog
 
 Ideas that will be planned and find their way into a release at one point
 
-- [ ] Address the 25 remaining test failures that are currently skipped (find out which ones via `npm run test:languages:noskip`)
-- [ ] Compare example test cases for PHP against `php -r` to make sure they are correctly mimicking the most recent stable behavior
-- [ ] Have _one_ way of checking pure JS arrays vs PHP arrays (vs: `Object.prototype.toString.call(arr1) === '[object Array]'`, `typeof retObj[p] === 'object'`, `var asString = Object.prototype.toString.call(mixedVar) var asFunc = _getFuncName(mixedVar.constructor) if (asString === '[object Object]' && asFunc === 'Object') {` )
-- [ ] Investigate if we can have one helper function for intersecting, and use that in all `array_*diff*` and `array_*sort*` functions. Refrain from using `labels`, which those functions currently still rely on
+- [ ] Address the 25 remaining test failures that are currently skipped (find out which ones via
+      `npm run test:languages:noskip`)
+- [ ] Compare example test cases for PHP against `php -r` to make sure they are correctly mimicking the most recent
+      stable behavior
+- [ ] Have _one_ way of checking pure JS arrays vs PHP arrays (vs:
+      `Object.prototype.toString.call(arr1) === '[object Array]'`, `typeof retObj[p] === 'object'`,
+      `var asString = Object.prototype.toString.call(mixedVar) var asFunc = _getFuncName(mixedVar.constructor) if (asString === '[object Object]' && asFunc === 'Object') {`
+      )
+- [ ] Investigate if we can have one helper function for intersecting, and use that in all `array_*diff*` and
+      `array_*sort*` functions. Refrain from using `labels`, which those functions currently still rely on
 - [ ] Investigate if we can have one helper function for sorting, and use that in all `*sort*` functions
-- [ ] Investigate if we can have one helper function to resolve `Function/'function'/'Class::function'/[$object, 'function']`, and use that in `is_callable`, `array_walk`, `call_user_func_array` etc.
+- [ ] Investigate if we can have one helper function to resolve
+      `Function/'function'/'Class::function'/[$object, 'function']`, and use that in `is_callable`, `array_walk`,
+      `call_user_func_array` etc.
 - [ ] Parse `require`s with AST just like Browserify does. Then we can add dependencies back to website
 - [ ] Port a few more tricky/inter-depending Go functions
 - [ ] Port a few more tricky/inter-depending Python functions
@@ -31,86 +38,76 @@ Ideas that will be planned and find their way into a release at one point
 
 ## main
 
-Released: TBA.
-[Diff](https://github.com/locutusjs/locutus/compare/v2.0.16...main).
+Released: TBA. [Diff](https://github.com/locutusjs/locutus/compare/v2.0.16...main).
 
 - [ ]
 
 ## v2.0.16
 
-Released: 2019-06-12.
-[Diff](https://github.com/locutusjs/locutus/compare/v2.0.10...v2.0.16).
+Released: 2019-06-12. [Diff](https://github.com/locutusjs/locutus/compare/v2.0.10...v2.0.16).
 
 - [x] Switch from Travis CI to GitHub Actions
 - [x] Fix ReDOS on IPv6
 - [x] Basic timezone support in strtotime
 
 ## v2.0.11
 
-Released: 2019-06-12.
-[Diff](https://github.com/locutusjs/locutus/compare/v2.0.10...v2.0.11).
+Released: 2019-06-12. [Diff](https://github.com/locutusjs/locutus/compare/v2.0.10...v2.0.11).
 
 - [x] functions: Community-contributed function improvements, see respective functions' changelogs in the Diff:
 - [x] ci: test Node.js 6, 8, 10 and 11 (#384)
 - [x] website: Fix code listing on locutus website (#379)
 
 ## v2.0.10
 
-Released: 2018-09-07.
-[Diff](https://github.com/locutusjs/locutus/compare/v2.0.9...v2.0.10).
+Released: 2018-09-07. [Diff](https://github.com/locutusjs/locutus/compare/v2.0.9...v2.0.10).
 
 - [x] functions: Community-contributed function improvements, see respective functions' changelogs in the Diff.
 
 ## v2.0.9
 
-Released: 2017-06-22.
-[Diff](https://github.com/locutusjs/locutus/compare/v2.0.8...v2.0.9).
+Released: 2017-06-22. [Diff](https://github.com/locutusjs/locutus/compare/v2.0.8...v2.0.9).
 
 - [x] functions: Community-contributed function improvements, see respective functions' changelogs in the Diff.
 
 ## v2.0.8
 
-Released: 2017-02-23.
-[Diff](https://github.com/locutusjs/locutus/compare/v2.0.7...v2.0.8).
+Released: 2017-02-23. [Diff](https://github.com/locutusjs/locutus/compare/v2.0.7...v2.0.8).
 
 - [x] Upgrade eslint and fix newly found issues accordingly
 - [x] functions: Community-contributed function improvements, see respective functions' changelogs in the Diff.
 
 ## v2.0.7
 
-Released: 2017-02-09.
-[Diff](https://github.com/locutusjs/locutus/compare/v2.0.6...v2.0.7).
+Released: 2017-02-09. [Diff](https://github.com/locutusjs/locutus/compare/v2.0.6...v2.0.7).
 
 - [x] functions: Community-contributed function improvements, see respective functions' changelogs in the Diff.
 
 ## v2.0.6
 
-Released: 2016-06-16.
-[Diff](https://github.com/locutusjs/locutus/compare/v2.0.5...v2.0.6).
+Released: 2016-06-16. [Diff](https://github.com/locutusjs/locutus/compare/v2.0.5...v2.0.6).
 
 - [x] Language fixes
 
 ## v2.0.5
 
-Released: 2016-06-16.
-[Diff](https://github.com/locutusjs/locutus/compare/v2.0.4...v2.0.5).
+Released: 2016-06-16. [Diff](https://github.com/locutusjs/locutus/compare/v2.0.4...v2.0.5).
 
 - [x] Cache node modules on Travis so we'll be less dependent on npm connectivity
 
 ## v2.0.4
 
-Released: 2016-05-25.
-[Diff](https://github.com/locutusjs/locutus/compare/v2.0.3...v2.0.4).
+Released: 2016-05-25. [Diff](https://github.com/locutusjs/locutus/compare/v2.0.3...v2.0.4).
 
 - [x] Upgrade depurar to 0.2.2, fixing an issue with the testwriter (@kukawski)
 - [x] Add the 'reimplemented by' and 'parts by' contributionKeys to the /authors website page
 - [x] Fix linting warnings when hacking on website by adding eslint dependencies locally
-- [x] Improve array_rand: Fix coding style, hangs when selected huge number of keys from huge array, function signature (@kukawski)
+- [x] Improve array_rand: Fix coding style, hangs when selected huge number of keys from huge array, function signature
+      (@kukawski)
 
 ## v2.0.3
 
-Released: 2016-05-22.
-[Diff](https://github.com/locutusjs/locutus/compare/v2.0.2...v2.0.3).
+Released: 2016-05-22. [Diff](https://github.com/locutusjs/locutus/compare/v2.0.2...v2.0.3).
 
 - [x] Minor `util.js` refactoring
 - [x] Use hexo deploy instead of custom bash script to aid Windows compatibility
@@ -128,22 +125,19 @@ Released: 2016-05-22.
 
 ## v2.0.2
 
-Released: 2016-05-02.
-[Diff](https://github.com/locutusjs/locutus/compare/v2.0.1...v2.0.2).
+Released: 2016-05-02. [Diff](https://github.com/locutusjs/locutus/compare/v2.0.1...v2.0.2).
 
 - [x] Don't use `files` in package.json as we don't ship all of `dist` now
 
 ## v2.0.1
 
-Released: 2016-05-02.
-[Diff](https://github.com/locutusjs/locutus/compare/v2.0.0...v2.0.1).
+Released: 2016-05-02. [Diff](https://github.com/locutusjs/locutus/compare/v2.0.0...v2.0.1).
 
 - [x] Don't use `bin` in package.json as we don't ship `cli.js`
 
 ## v2.0.0
 
-Released: 2016-05-02.
-[Diff](https://github.com/locutusjs/locutus/compare/v1.3.2...v2.0.0).
+Released: 2016-05-02. [Diff](https://github.com/locutusjs/locutus/compare/v1.3.2...v2.0.0).
 
 - [x] website: Add profile to sidebar
 - [x] Rename `_locutus_shared` to `_helpers`. Rename `_locutus_shared_bc` to `_bc`
@@ -173,7 +167,8 @@ Released: 2016-05-02.
 - [x] Make Travis fail on eslint issues
 - [x] Move CHANGELOG to own file
 - [x] Make all functions pass eslint with JavaScript Standard Style
-- [x] Remove `_workbench` and `_experimental`. They are available for reference in `1.3.2` but making them harder to find for newcomers should help avoid a lot of complaints
+- [x] Remove `_workbench` and `_experimental`. They are available for reference in `1.3.2` but making them harder to
+      find for newcomers should help avoid a lot of complaints
 - [x] Move functions that overly rely on ini & locales & global & ajax file operations to \_legacy
 - [x] Address ~50 test failures that were previously skipped and now enabled
 - [x] `json_*` functions can leverage Node's

CONDUCT.md

@@ -1,8 +1,12 @@
 # Contributor Code of Conduct
 
-As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.
+As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we
+pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation,
+submitting pull requests or patches, and other activities.
 
-We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality.
+We are committed to making participation in this project a harassment-free experience for everyone, regardless of level
+of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size,
+race, ethnicity, age, religion, or nationality.
 
 Examples of unacceptable behavior by participants include:
 
@@ -13,10 +17,17 @@ Examples of unacceptable behavior by participants include:
 - Publishing other's private information, such as physical or electronic addresses, without explicit permission
 - Other unethical or unprofessional conduct.
 
-Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project. Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team.
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits,
+issues, and other contributions that are not aligned to this Code of Conduct. By adopting this Code of Conduct, project
+maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this
+project. Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the
+project team.
 
-This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.
+This code of conduct applies both within project spaces and in public spaces when an individual is representing the
+project or its community.
 
-Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening an issue or contacting one or more of the project maintainers.
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening an issue or contacting
+one or more of the project maintainers.
 
-This Code of Conduct is adapted from the [Contributor Covenant](https://contributor-covenant.org), version 1.2.0, available at [https://contributor-covenant.org/version/1/2/0/](https://contributor-covenant.org/version/1/2/0/)
+This Code of Conduct is adapted from the [Contributor Covenant](https://contributor-covenant.org), version 1.2.0,
+available at [https://contributor-covenant.org/version/1/2/0/](https://contributor-covenant.org/version/1/2/0/)

CONTRIBUTING.md

@@ -1,25 +1,31 @@
 Thank you so much for being or becoming a Locutus contributor!
 
-Even if you have write access already, all code changes should be done via a Pull Request. This way
-we can peer-review, and also GitHub Actions can check if the code adheres to our policies already before
-merging it into `main`.
+Even if you have write access already, all code changes should be done via a Pull Request. This way we can peer-review,
+and also GitHub Actions can check if the code adheres to our policies already before merging it into `main`.
 
 ## Contributing Checklist
 
 Here are a few pointers that could save us from disappointment, we'll try to keep it brief!
 
 1. By submitting a Pull Request you are giving Locutus permission to distribute your code under the MIT License.
-1. Please adhere to our [updated coding standards](/blog/2016/04/standard-coding-style/). Use `npm run lint` to check. Code should:
+1. Please adhere to our [updated coding standards](/blog/2016/04/standard-coding-style/). Use `npm run lint` to check.
+   Code should:
 
 - Follow the [JavaScript Standard Style](https://standardjs.com/), and in addition:
 - Not have lines longer than 100 chars
 - Use `//` for comments instead of `/*`
 - Avoid using lengthy (3+ word) comments on the same line as code
 
-1. Please credit yourself in the function's header-comment: `(original by|reimplemented by|improved by|parts by|bugfixed by|revised by|input by): Your Name (https://your.url)`
-1. If you are fixing bad behavior, or introducing new ones, please add an `example` that would fail before your patch, and a `result` that passes after your patch, to the function's header-comment. We use these for website documentation, as well as to generate test cases that avoid regression going forward. There should already be a few ones there if you want to see how it's done.
+1. Please credit yourself in the function's header-comment:
+   `(original by|reimplemented by|improved by|parts by|bugfixed by|revised by|input by): Your Name (https://your.url)`
+1. If you are fixing bad behavior, or introducing new ones, please add an `example` that would fail before your patch,
+   and a `result` that passes after your patch, to the function's header-comment. We use these for website
+   documentation, as well as to generate test cases that avoid regression going forward. There should already be a few
+   ones there if you want to see how it's done.
 1. If you are contributing performance upgrades, please provide proof via e.g. <https://jsperf.com>
-1. Please keep in mind that some obvious readability improvements are sometimes unwanted for performance reasons. For example, we sometimes place similar `for` loops inside `if` and `else` conditions for performance reasons, even though the code could be half the size if we put the conditions inside a single loop.
+1. Please keep in mind that some obvious readability improvements are sometimes unwanted for performance reasons. For
+   example, we sometimes place similar `for` loops inside `if` and `else` conditions for performance reasons, even
+   though the code could be half the size if we put the conditions inside a single loop.
 1. If you are adding a new function, please make sure to:
 
 - include exactly one export with a named function, `module.exports = function functionName (param1, ...) {`
@@ -68,9 +74,11 @@ Single out one function: `natsort`
 TEST_GREP=natsort yarn test:languages
 ```
 
-This first rewrites mocha test-cases based on `example` and `result` comments found in the function's headers. This is useful if you're changing the tests themselves as well.
+This first rewrites mocha test-cases based on `example` and `result` comments found in the function's headers. This is
+useful if you're changing the tests themselves as well.
 
-If that's not needed as you're iterating purely on the implementation, here's a speedier way of singling out `natsort`. This re-uses an already generated mocha test:
+If that's not needed as you're iterating purely on the implementation, here's a speedier way of singling out `natsort`.
+This re-uses an already generated mocha test:
 
 ```bash
 env DEBUG=locutus:* ./node_modules/.bin/mocha \
@@ -81,18 +89,25 @@ test/languages/php/array/test-natsort.js
 
 ### Website Development
 
-We keep the website in `./website` so it's easy to keep code and website in sync as we iterate. For those reading this screaming murder, [HashiCorp does this](https://github.com/hashicorp/terraform/tree/HEAD/website) for all their projects, and it's working well for them on a scale more impressive than ours.
+We keep the website in `./website` so it's easy to keep code and website in sync as we iterate. For those reading this
+screaming murder, [HashiCorp does this](https://github.com/hashicorp/terraform/tree/HEAD/website) for all their
+projects, and it's working well for them on a scale more impressive than ours.
 
 Our website is built with Hexo. To install the prerequisites type `yarn website:install`.
 
-Even the the website is bundled with this repo, we treat it as a separate project, with its own `package.json`. We also try to avoid dependencies from the website straight to the main code base. Instead, any such dependency shall be injected by a script.
+Even the the website is bundled with this repo, we treat it as a separate project, with its own `package.json`. We also
+try to avoid dependencies from the website straight to the main code base. Instead, any such dependency shall be
+injected by a script.
 
 Here's the flow that takes written functions to the website:
 
 - `yarn injectweb` runs `src/_util/util.js`'s `injectweb` method
-- `injectweb` iterates over functions and parses them via the `_load` and `_parse` methods, specifically: the header comments that declare authors, tests, and dependencies
-- `injectweb` then writes each function to `website/source`. The code is written as the content. The other parsed properties are prepended as [YAML front matter](https://jekyllrb.com/docs/frontmatter/)
-- Jekyll uses `website/_layouts/function.html` as the layout template for the function collection, this determines how all the properties are rendered.
+- `injectweb` iterates over functions and parses them via the `_load` and `_parse` methods, specifically: the header
+  comments that declare authors, tests, and dependencies
+- `injectweb` then writes each function to `website/source`. The code is written as the content. The other parsed
+  properties are prepended as [YAML front matter](https://jekyllrb.com/docs/frontmatter/)
+- Jekyll uses `website/_layouts/function.html` as the layout template for the function collection, this determines how
+  all the properties are rendered.
 
 Blog posts can be found in `website/source/_posts`.