Skip to content

Commit

Permalink
fix: remark-lint whitespace rules (#978)
Browse files Browse the repository at this point in the history 
* chore: Add EditorConfig for whitespace

* fix: remark-lint-final-newline

* fix: remark-lint-no-trailing-spaces

* fix: remark-lint-hard-break-spaces

* fix: remark-lint-no-consecutive-blank-lines
  • Loading branch information
@nschonni
nschonni committed Mar 10, 2021
1 parent 105f5a4 commit 29681c4
Show file tree
Hide file tree
Showing 197 changed files with 3,233 additions and 3,799 deletions.
12 changes: 12 additions & 0 deletions .editorconfig
View file
@@ -0,0 +1,12 @@
# EditorConfig is awesome: https://EditorConfig.org

# top-most EditorConfig file
root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
4 changes: 0 additions & 4 deletions .remarkrc
View file
Expand Up @@ -4,19 +4,15 @@
"remark-preset-lint-node",
["remark-lint-fenced-code-flag", false],
["remark-lint-final-definition", false],
["remark-lint-final-newline", false],
["remark-lint-first-heading-level", false],
["remark-lint-hard-break-spaces", false],
["remark-lint-heading-style", false],
["remark-lint-list-item-bullet-indent", false],
["remark-lint-list-item-indent", false],
["remark-lint-maximum-line-length", false],
["remark-lint-no-consecutive-blank-lines", false],
["remark-lint-no-heading-content-indent", false],
["remark-lint-no-literal-urls", false],
["remark-lint-no-multiple-toplevel-headings", false],
["remark-lint-no-shortcut-reference-link", false],
["remark-lint-no-trailing-spaces", false],
["remark-lint-no-undefined-references", false],
["remark-lint-no-unused-definitions", false],
["remark-lint-prohibited-strings", false],
Expand Down
52 changes: 26 additions & 26 deletions Applications/Express.md
View file
Expand Up @@ -17,21 +17,21 @@ Node.js ecosystem and that by incubating Express, neither the Node.js
Foundation or Node.js core would be "picking a winner" or endorsing Express
over any other overlapping or similar project.

### Scope
### Scope

The express project is composed of a collection of separate modules and
documentation currently spread out over multiple GitHub organizations. This top
The express project is composed of a collection of separate modules and
documentation currently spread out over multiple GitHub organizations. This top
level project would consist initially of the following GitHub Organizations and
repositories within:

* jshttp
* expressjs
* pillarjs

The existing strongloop/express repository will move into one of these three
The existing strongloop/express repository will move into one of these three
organizations.

In addition, StrongLoop will contribute the basic express API documentation
In addition, StrongLoop will contribute the basic express API documentation
included in the strongloop/expressjs.com to the strongloop/express repository.

Many repositories in these organizations may be moved out or removed entirely
Expand All @@ -44,28 +44,28 @@ managed.

### Formation of an Express TC

The current GitHub organization owners for each of the pillarjs, expressjs,
and jshttp GitHub organizations will be invited to form the TC of the Express
Top Level project. It is not expected that every existing owner will wish to
participate. Two months after the initial invitation, any owner that is not
The current GitHub organization owners for each of the pillarjs, expressjs,
and jshttp GitHub organizations will be invited to form the TC of the Express
Top Level project. It is not expected that every existing owner will wish to
participate. Two months after the initial invitation, any owner that is not
actively participating would be automatically removed from the TC.

Ownership permissions in the pillarjs, expressjs, and jshttp GitHub
organizations shall include all members of the Express TC as well as the
Ownership permissions in the pillarjs, expressjs, and jshttp GitHub
organizations shall include all members of the Express TC as well as the
mentors nominated by the Node.js TSC.

Collaborators currently having permissions to any of the repositories in the
pillarjs, expressjs and jshttp GitHub organizations will continue to have those
permissions. From the StrongLoop GitHub organization, users Rand McKinney
(@crandmck), Hage Yaapa (@hacksparrow), Mike Tunnicliffe (@tunniclm), and Sian
January (@sjanuary) will continue to have Collaborator permissions to
Collaborators currently having permissions to any of the repositories in the
pillarjs, expressjs and jshttp GitHub organizations will continue to have those
permissions. From the StrongLoop GitHub organization, users Rand McKinney
(@crandmck), Hage Yaapa (@hacksparrow), Mike Tunnicliffe (@tunniclm), and Sian
January (@sjanuary) will continue to have Collaborator permissions to
strongloop/express (in whichever GitHub organization it ends up).

Onboarding of new Collaborators would follow a process decided by the Express
TC but it is expected to be similar, if not identical, to the process used by
Onboarding of new Collaborators would follow a process decided by the Express
TC but it is expected to be similar, if not identical, to the process used by
Node.js core.

The Express TC's purpose is the support, maintenance and further development of
The Express TC's purpose is the support, maintenance and further development of
the Express top level project under the Node.js Foundation.

The TC's responsibilities include:
Expand All @@ -81,15 +81,15 @@ The TC's responsibilities include:

### Contribution and Governance Process

The contribution and governance policies would be bootstrapped using the basic
document templates provided by the Node.js TSC, and fine tuned / customized by
the Express TC once formed. It is expected that the contribution policy would
be very similar to that used by Node.js core.
The contribution and governance policies would be bootstrapped using the basic
document templates provided by the Node.js TSC, and fine tuned / customized by
the Express TC once formed. It is expected that the contribution policy would
be very similar to that used by Node.js core.

The Node.js Code of Conduct, Moderation Policy and TSC Escalation policies
would apply.
The Node.js Code of Conduct, Moderation Policy and TSC Escalation policies
would apply.

The Node.js TSC will select one or more mentors to assist the Express TC in
The Node.js TSC will select one or more mentors to assist the Express TC in
it's formation and throughout the Top Level Project incubation process.

### Intellectual Property and Other Assets
Expand Down
34 changes: 17 additions & 17 deletions BasePolicies/CONTRIBUTING.md
View file
Expand Up @@ -19,19 +19,19 @@ and the Node.js project.

* A **Contributor** is any individual creating or commenting on an issue or pull request.
* A **Committer** is a subset of contributors who have been given write access to the repository.
* A **TC (Technical Committee)** is a group of committers representing the required technical
* A **TC (Technical Committee)** is a group of committers representing the required technical
expertise to resolve rare disputes.

# Logging Issues

Log an issue for any question or problem you might have. When in doubt, log an issue,
Log an issue for any question or problem you might have. When in doubt, log an issue,
any additional policies about what to include will be provided in the responses. The only
exception is security disclosures which should be sent privately.

Committers may direct you to another repository, ask for additional clarifications, and
add appropriate metadata before the issue is addressed.

Please be courteous, respectful, and every participant is expected to follow the
Please be courteous, respectful, and every participant is expected to follow the
project's Code of Conduct.

# Contributions
Expand All @@ -43,24 +43,24 @@ pull requests.
No pull request can be merged without being reviewed.

For non-trivial contributions, pull requests should sit for at least 36 hours to ensure that
contributors in other timezones have time to review. Consideration should also be given to
weekends and other holiday periods to ensure active committers all have reasonable time to
contributors in other timezones have time to review. Consideration should also be given to
weekends and other holiday periods to ensure active committers all have reasonable time to
become involved in the discussion and review process if they wish.

The default for each contribution is that it is accepted once no committer has an objection.
During review committers may also request that a specific contributor who is most versed in a
particular area gives a "LGTM" before the PR can be merged. There is no additional "sign off"
process for contributions to land. Once all issues brought by committers are addressed it can
During review committers may also request that a specific contributor who is most versed in a
particular area gives a "LGTM" before the PR can be merged. There is no additional "sign off"
process for contributions to land. Once all issues brought by committers are addressed it can
be landed by any committer.

In the case of an objection being raised in a pull request by another committer, all involved
committers should seek to arrive at a consensus by way of addressing concerns being expressed
In the case of an objection being raised in a pull request by another committer, all involved
committers should seek to arrive at a consensus by way of addressing concerns being expressed
by discussion, compromise on the proposed change, or withdrawal of the proposed change.

If a contribution is controversial and committers cannot agree about how to get it to land
or if it should land then it should be escalated to the TC. TC members should regularly
discuss pending contributions in order to find a resolution. It is expected that only a
small minority of issues be brought to the TC for resolution and that discussion and
discuss pending contributions in order to find a resolution. It is expected that only a
small minority of issues be brought to the TC for resolution and that discussion and
compromise among committers be the default resolution mechanism.

# Becoming a Committer
Expand All @@ -73,18 +73,18 @@ proper review, and have other committers merge their pull requests.

# TC Process

The TC uses a "consensus seeking" process for issues that are escalated to the TC.
The TC uses a "consensus seeking" process for issues that are escalated to the TC.
The group tries to find a resolution that has no open objections among TC members.
If a consensus cannot be reached that has no objections then a majority wins vote
is called. It is also expected that the majority of decisions made by the TC are via
is called. It is also expected that the majority of decisions made by the TC are via
a consensus seeking process and that voting is only used as a last-resort.

Resolution may involve returning the issue to committers with suggestions on how to
move forward towards a consensus. It is not expected that a meeting of the TC
Resolution may involve returning the issue to committers with suggestions on how to
move forward towards a consensus. It is not expected that a meeting of the TC
will resolve all issues on its agenda during that meeting and may prefer to continue
the discussion happening among the committers.

Members can be added to the TC at any time. Any committer can nominate another committer
to the TC and the TC uses its standard consensus seeking process to evaluate whether or
not to add this new member. Members who do not participate consistently at the level of
not to add this new member. Members who do not participate consistently at the level of
a majority of the other members are expected to resign.
2 changes: 1 addition & 1 deletion CODE_OF_CONDUCT.md
View file
Expand Up @@ -4,4 +4,4 @@ The Technical Steering Committee is committed to upholding the Node.js Code of C

The Node.js Code of Conduct document has moved to
https://github.com/nodejs/admin/blob/master/CODE_OF_CONDUCT.md Please update
links to this document accordingly.
links to this document accordingly.
29 changes: 8 additions & 21 deletions OpenSSL-Strategy.md
View file
Expand Up @@ -12,14 +12,12 @@ This policy document describes for each release line:
It also gives background on OpenSSL release lifetimes, TLS1.3, and FIPS support,
as they affect Node.js.


## Node.js version-specific strategy

### Node.js version 4.x (EOL 2018-04-30)

No longer maintained. Not discussed further.


### Node.js versions 6.x (EOL 2019-04-30) and 8.x (EOL 2019-12-31)

Node.js 6.x and 8.x have the same OpenSSL versions and policies.
Expand All @@ -35,7 +33,6 @@ but it was moved earlier to conincide with the end-of-life of OpenSSL 1.0.2.
configuration is not default, and OpenSSL FIPS 2.0 is not included in
Node.js.


### Node.js version 10.x (EOL April-2021)

OpenSSL LTS support timing, the lack of OpenSSL LTS planning and the lack of a
Expand Down Expand Up @@ -85,7 +82,6 @@ line. There is no indication yet that this will happen when OpenSSL 1.1.1 is
included in Node.js 10.x, but it is important that users be aware of this
possibility.


### Node.js version 11.x (EOL June-2019)

This release will not be designated LTS. It was updated to include OpenSSL 1.1.1
Expand All @@ -106,7 +102,6 @@ For Node.js >= 11.9.0:
supported by default, only by explicit run-time configuration.
* FIPS: not supported


### Node.js version 12.x, 13.x, 14.x

* OpenSSL version: 1.1.1
Expand All @@ -116,7 +111,6 @@ For Node.js >= 11.9.0:
configuration.
* FIPS: not supported


Node.js EOL dates:
- 12.x: April 2022
- 13.x: June, 2020
Expand Down Expand Up @@ -157,17 +151,17 @@ building against OpenSSL 1.1.1 out-of-tree, even if OpenSSL 3.x was in-tree.

Challenges are:
1. OpenSSL 3.x moved many algorithms into a legacy library, that is only
accessible as a dynamically loaded provider, so cannot ship with Node.js
accessible as a dynamically loaded provider, so cannot ship with Node.js
2. Node.js has a build system wrapped around OpenSSL 1.1.1, it is currently
incompatible with the OpenSSL 3.x build system (effort to fix this is
unknown).
incompatible with the OpenSSL 3.x build system (effort to fix this is
unknown).
3. OpenSSL 3.x has compile-time warning-deprecated a number of OpenSSL 1.1.1
APIs, but the alternatives to those deprecated APIs do not exist in OpenSSL
1.1.1. So, Node.js 16.x either needs to ship calling deprecated APIs, or
break compatibility with OpenSSL 1.1.1 (so it will _only build with 3.x_).
APIs, but the alternatives to those deprecated APIs do not exist in OpenSSL
1.1.1. So, Node.js 16.x either needs to ship calling deprecated APIs, or
break compatibility with OpenSSL 1.1.1 (so it will _only build with 3.x_).
4. Behavioural differences in OpenSSL 3.x currently fail many tests in the
Node.js master test suite (effort to fix this is unknown, impact of fixing
in terms of compatibility is unknown).
Node.js master test suite (effort to fix this is unknown, impact of fixing
in terms of compatibility is unknown).

Tracking issue: https://github.com/nodejs/node/issues/29817

Expand Down Expand Up @@ -221,8 +215,6 @@ OpenSSL. The most notable distributors and the configurations used are:
version of OpenSSL that was most recently installed with `brew` but this is
not believed to be in common use.



## OpenSSL release lines

Currently, there are three supported versions of OpenSSL as per the
Expand Down Expand Up @@ -302,7 +294,6 @@ source:
order to speed up some of the Node.js TLS tests. Use of this can be found in
many of the `test/*/test-{tls,https}-*` test files.


### OpenSSL 1.1.0

OpenSSL 1.1.0 represents a fairly major rework of the codebase, at least in
Expand All @@ -318,7 +309,6 @@ an important stage in Node.js' adaptation.
Openssl 1.1.0 is currently included in Node.js 10.x, but Node.js is expected to
be updated to include OpenSSL 1.1.1 in the upcoming 10.16.0 release.


### OpenSSL 1.1.1

The OpenSSL team has designated 1.1.1 the next LTS line and have made a
Expand All @@ -327,7 +317,6 @@ and will be supported until 2023-09-11. It is the first OpenSSL version to
support TLS 1.3, however Node.js' TLS1.3 support requires at least OpenSSL
1.1.1b.


### OpenSSL 3.0.0 and FIPS

The next release of OpenSSL will be 3.0.0. It is skipping 2.0 because that
Expand Down Expand Up @@ -358,7 +347,6 @@ release of Node.js that supports FIPS coming in April, 2020.

At this point, the gap looks unavoidable.


## OpenSSL forks: LibreSSL and BoringSSL

**Node.js does not officially support compiling against OpenSSL-compatible
Expand Down Expand Up @@ -402,4 +390,3 @@ support.
[OpenSSL Release Strategy]: https://www.openssl.org/policies/releasestrat.html
[OpenSSL 3.0 and FIPS Update]: https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/
[OpenSSL 3.0.0 Design]: https://www.openssl.org/docs/OpenSSL300Design.html

0 comments on commit 29681c4

Please sign in to comment.