profile
viewpoint
Myles Borins MylesBorins @Google New York, New York https://mylesborins.com Artist, musician, developer, and maker / @nodejs TSC / @openjsf Director / @tc39 Co-Chair / Open Source Programs Office @google

gregsramblings/google-cloud-4-words 3624

The Google Cloud Developer's Cheat Sheet

google/node-sec-roadmap 155

Some thoughts on how Node.js might respond to a changing security environment

brianloveswords/base64url 151

For encoding and decoding base64url!

GoogleCloudPlatform/nodejs-serverless-microservices-demo 72

A set of Node.js microservices to track visual changes of web pages.

GoogleCloudPlatform/wombat-dressing-room 71

proxy designed to reduce the attack surface of npm publish

monome/aleph 68

open source sound computer

GoogleCloudPlatform/nodejs-serverless-url-shortener 16

A link shortening service built on Google Cloud

jkup/one-line 10

A Node.js app where you can only contribute one line at a time

mikeal/dogpatchjs 9

Website for DogpatchJS

issue openednodejs/node

Better error message for using static import in repl

We don't support using static import in the repl, we should give a more meaningful error message

created time in 11 hours

issue commentnodejs/modules

Module Attributes RFC

FYI there is a discussion happening in the openjs standards working group about this proposal. If folks could chime in it would be helpful

https://github.com/openjs-foundation/standards/issues/91

bmeck

comment created time in 14 hours

issue commentbabel/babel

No "exports" main resolved in @babel/helper-compilation-targets/package.json with Node 12.17.0

FTR I had to blow away the entire lockfile and run npm install again to get the right dependency graph

JamesSingleton

comment created time in 15 hours

issue commentopenjs-foundation/standards

Discuss foundation TC39 delegate expectations

@devsnek a TC39 delegate of OpenJS is a representative of our foundation at the committee. When opinions are expressed and shared it is important to be able to distinguish between those of the individual and those of the organization.

I think if a delegate has technical concerns that have some bearing in reality, it's reasonable for them to block on that without having to muster up the consensus of the org

This is an extremely difficult thing to gauge, as we may not have consensus that the technical concerns have bearing in reality... that is subjective.

I think an important premise here, which we may not agree on, is the purpose and role of a OpenJS rep at TC39. A couple I can think of right away:

  1. Represent the views / opinions of OpenJS to the committee
  2. Giving access to the committee to our community members
  3. Bring subject matter expertise the committee would otherwise not have.

If a subject matter expert is unable to build some degree of consensus within the foundation of their position, and that we should indeed be blocking a proposal I do not believe that it aligns with the first goal of representing the view / opinions of OpenJS to the committee.

I also don't think that the need to build internal consensus works against the goal of giving access to the committee, folks can attend and participate in the meetings. I'm not even against individuals bringing their opinions and presenting them. If we do not have consensus around a block I see no concern with an OpenJS delegate making it clear to Tc39 that they, and potentially certain projects, have concerns with the proposal and while they are not blocking as there is not foundation wide consensus they would like to encourage others to reconsider the decision.

What I am not ok with is a representative of the foundation taking a nuclear option at the committee due to their own opinions that have not built consensus.

ljharb

comment created time in 16 hours

push eventtc39/proposal-module-attributes

ghpages auto deploy

commit sha 1aa46c1d452c5c6c41b662646abf18b635f5b502

Automated deployment: Tue May 26 19:26:34 UTC 2020 9811975a7533f4b3c03ae581f5a7096d46d5b04d

view details

push time in 16 hours

issue commentbabel/babel

No "exports" main resolved in @babel/helper-compilation-targets/package.json with Node 12.17.0

Looks like the issue was an out of date version of helper-compilation-target in the package-lock. I've opened a PR that should fix this.

https://github.com/americanexpress/holocron/pull/35

Once that has confirmed to fix stuff I think this issue can be closed.

JamesSingleton

comment created time in 17 hours

pull request commentamericanexpress/holocron

chore(version-bump): @babel/core and update package-lock

Unfortunately I will be unable to sign your CLA, so please feel free to close this. Wanted to show how to get things working, should be easy enough to open a new PR.

MylesBorins

comment created time in 17 hours

push eventMylesBorins/holocron

Myles Borins

commit sha c3b2fe97f4471d4eef97d4eca280744fad80ccd9

chore(version-bump): @babel/core and update package-lock

view details

push time in 17 hours

PR opened americanexpress/holocron

chore(version-bump): @babel/core and update package-lock

This fixes support for node.js 12.17.0

+3578 -3112

0 comment

2 changed files

pr created time in 17 hours

push eventMylesBorins/holocron

Myles Borins

commit sha 43e2c72bc2435319d20b416deb14094b2d271815

chore(version-bump): u@babel/core and update package-lock

view details

push time in 17 hours

create barnchMylesBorins/holocron

branch : fix-on-node-12

created branch time in 17 hours

fork MylesBorins/holocron

✨Set of packages that are used to compose and load React components, enabling the updating and launching of server side rendered user experiences without server restarts

fork in 17 hours

issue commentbabel/babel

No "exports" main resolved in @babel/helper-compilation-targets/package.json with Node 12.17.0

@JamesSingleton I was unable to reproduce locally with the exact same babel config and the following dependencies

  "dependencies": {
    "@babel/cli": "^7.8.4",
    "@babel/core": "^7.9.6"
  }

Do you have an example of the code you are attempting to transpile?

JamesSingleton

comment created time in 17 hours

issue commentopenjs-foundation/standards

Discuss foundation TC39 delegate expectations

@ljharb the action is "blocking consensus for advancement"... that action should have consensus. I guess what we are talking about here is what the default mode should be... but this is the difference between consensus and unanimity. You don't need everyone to say "yes" to have consensus... you simply need no one to be objecting.

An objection in turn then actively blocks the consensus for advancement. This type of objection comes at a cost... social + physical (time). This type of action should not happen without consensus at the foundation, is the premise I've been saying this entire time.

Letting the committee know that OpenJS does not have consensus for advancement but is not actively blocking seems like a good middle ground in the case where we do not have consensus on the block. That could be enough to encourage other delegates to block. In lieu of anyone else blocking, and not having consensus to block in OpenJS, it would seem to me that we should not be the lone blocker.

ljharb

comment created time in 18 hours

issue commentopenjs-foundation/standards

Discuss foundation TC39 delegate expectations

@ljharb I disagree with your premise that it is disenfranchising and that a primary way to engage in the committee is through having the ability to block

ljharb

comment created time in 18 hours

issue commentopenjs-foundation/standards

[TC39] Potentially blocking "Module Attributes" proposal

@dtex the module attributes proposal is the current best possible path to natively supporting json modules in JavaScript (allowing JSON to be imported).

One of the biggest groups this affects is the node.js modules team... which does not have consensus on the proposal (Myself, Jordan, and Gus are all members)

devsnek

comment created time in 18 hours

issue commentopenjs-foundation/standards

Discuss foundation TC39 delegate expectations

@mikesamuel I have to be honest that I'm having a hard time following the logic here.

If many members of an SSO were to require blocking votes to be discussed beforehand then the SSO as a whole would be less resistant to this kind of abuse.

I don't really see how this scales to TC39. Any single member can join and block a proposal. That is the risk. I don't really see how stacking standards bodies with folks to vote has anything to do with the discussion here about if OpenJS reps should block.

I've stated previously that I don't think our delegates should be blocking without building some degree of consensus... since we are very likely to have a mix of folks both for + against the proposal in OpenJS I'm not really sure how we move this forward. Does a lack of clear consensus mean a block is not possible? Do we merely require a certain threshold of +1s? It would seem like it could get fairly complicated fairly quickly here... which is leading me to a potentially more drastic conclusion. Perhaps this shouldn't be a flexible thing... either we allow our delegates to block, or we don't.

It seems to me extremely rare that a controversial block would ever be able to build consensus in OpenJS, maybe that's ok.

ljharb

comment created time in 19 hours

issue commentopenjs-foundation/standards

[TC39] Potentially blocking "Module Attributes" proposal

So, and this is where my input might need to be recused... I disagree with the block.

@ljharb the hazard argument does not make sense in a world where folks are including the file extension. The security concerns that were raised by the W3C folks were specifically about a privilege escalation attack if a json module were to be changed to be a JS module. The proposal does not preclude other means of identifying module type, such as out of band metadata... so if you wanted to write code in an environment that supported file extension resolution + out of band meta data it would work.

Based on your belief that the only place the type should be defined is the export site, not the import site. there is no path forward to getting officially supported JSON module in the JS platform that would be supported by both browsers and severside runtimes.

I think we might want to be careful about this issue turning into a pile on of feedback back and forth... although perhaps if there isn't clear consensus in the issue, that should make it clear that we should not be blocking as a foundation. Alternatively if there is strong enough voice + evidence that a block should happen perhaps that would be enough. I'll bring meta conversation to https://github.com/openjs-foundation/standards/issues/84

I'll speak to Gus's more specific blocks with more research if we decide this is the right venue for the discussion

devsnek

comment created time in 19 hours

issue commentopenjs-foundation/standards

[TC39] Potentially blocking "Module Attributes" proposal

It might be necessary for us to have an out of band meeting to discuss process issues here, or potentially work it out in this thread. We have not yet reached any sort of consensus on what is needed for an OpenJS delegate to be able to block at a committee, or if they should even be able to.

We also have to consider the fact that multiple members of this working group are champions of the proposal that is potentially being blocked.

@devsnek we have talked about requiring a degree of consensus to bring forward a block. Have you done any work building consensus across OpenJS members about this?

devsnek

comment created time in 19 hours

Pull request review commentopenjs-foundation/cross-project-council

WIP doc: Goveranance changes for Collaboration Network

 ensuring:       substantial changes before final approval by CPC.    1. Voting members are responsible for approving funds for budgets delegated       to the project.+   1. Voting members are responsible for approving new `collaboration spaces` within the scope+      for OpenJS Foundation set by the Governing Board, as outlined in the OpenJS Collaboration Network process. 

within the scope for reads a bit odd. Is it necessary to be explicit there? Could it be simplified?

   1. Voting members are responsible for approving new `collaboration spaces` as outlined in the OpenJS 
   Collaboration Network process. 
mhdawson

comment created time in 20 hours

Pull request review commentopenjs-foundation/cross-project-council

WIP doc: Goveranance changes for Collaboration Network

 If you run your project's social media and would like the Foundation to share or  For any other topics which aren't covered above, please email [operations@openjsf.org](mailto:operations@openjsf.org).-

Is there no longer a newline at the end of the document?

mhdawson

comment created time in 20 hours

Pull request review commentopenjs-foundation/cross-project-council

WIP doc: Goveranance changes for Collaboration Network

 According to the [CPC Charter](https://github.com/openjs-foundation/cross-projec - Christopher Hiller (@boneskull, IBM) - Tobie Langel (@tobie, UnlockOpen) +#### Collaboration space representatives++Members of the Collaboration spaces at the `Core` stage may nominate a candiate for one of the voting seats on the CPC which represents the Collaboration spaces. Currently there are no spaces at the `Core` stage and therefore no representative.

What is the Core phase? Where is the documentation for this?

mhdawson

comment created time in 20 hours

Pull request review commentopenjs-foundation/cross-project-council

WIP doc: Goveranance changes for Collaboration Network

 The following projects are official OpenJS Foundation projects. If you are inter * [Fastify](https://fastify.io) * [nvm](http://nvm.sh/) ++### OpenJS Collaboration spaces++The following are official OpenJS Collaboration spaces. If you are interested in fostering collaboration with the +support of the OpenJS foundation through a collaboration space, please read our [Collaboration Space Progression]+

Should there be a note here that there are none? It seems weird for it to mention The following are official OpenJS Collaboration spaces but then have nothing blow

mhdawson

comment created time in 20 hours

issue commentopenjs-foundation/standards

[TC39] Potentially blocking "Module Attributes" proposal

I am one of the champions of this proposal, so I obviously have a bias here. Would it make sense for me to recuse myself from this conversation or should I actively participate?

devsnek

comment created time in 21 hours

push eventtc39/proposal-module-attributes

ghpages auto deploy

commit sha 9e7908c403b6fba5a11964f4ecd01a596a4ef83a

Automated deployment: Mon May 25 20:50:26 UTC 2020 20591398445b037a5998aea36de1fa6a86143deb

view details

push time in 2 days

push eventopenjs-foundation/standards

Tobie Langel

commit sha e0b6818ddc1ff2d42cec44bd310ccdf16ebfffb6

Follow the CoC of external organizations (#70) * Follow the CoC of external organizations * Update MEMBER_EXPECTATIONS.md Co-Authored-By: Jordan Harband <ljharb@gmail.com> Co-authored-by: Jordan Harband <ljharb@gmail.com>

view details

push time in 3 days

issue commentnodejs/nodejs.dev

Merge website redesign teams

@amiller-gh I think it shouldn't be an issue anymore

keywordnew

comment created time in 5 days

push eventMylesBorins/my-corona-data

Myles Borins

commit sha b5a9b6e78ef35ba4143856242d377bc9f88bb13a

Squashed 'third_party/coronavirus-data/' changes from 25021ca..c5cb741 c5cb741 5/21 data update 6948736 corrected time stamp d3a1873 5/21 data update f9dbf48 Corrected timestamp on summary.csv 0c4a03c 5/20 data upload e57a1f5 Fix problem with probable-confirmed-dod.csv a68f42f 5/19 data update 80df5dc Updated tests-by-zcta as of 5/18 c3c4d89 Restoring probable-confirmed-dod.csv dc8d2c0 Delete probable-confirmed-dod.csv 50e60ee 5/18 data update 67fdc83 5/17 data upload d9d894a 5/17 data upload git-subtree-dir: third_party/coronavirus-data git-subtree-split: c5cb7417b5ecb836f9727d6996f97d3cd050ba8d

view details

Myles Borins

commit sha 805157e88e01cd5a9a0259734f0f2ac4954533be

update city data

view details

Myles Borins

commit sha 3f16c1e9607e270d8d1df4bce447136fbfcf6cfb

update state data

view details

push time in 5 days

issue commentMylesBorins/node-osc

DEP0002 - Decoding TUIO

https://teams.microsoft.com/l/meetup-join/19%3ameeting_NWE4ZTZjZTYtYzE2Zi00M2E4LWE4MTYtYjJmNDA5YTVlZmZm%40thread.v2/0?context=%7b%22Tid%22%3a%2272f988bf-86f1-41af-91ab-2d7cd011db47%22%2c%22Oid%22%3a%22914d3126-620c-494d-b9a3-4a2115e3e828%22%7d

Sevenlive

comment created time in 5 days

push eventnodejs/Release

Beth Griggs

commit sha 6137754e645caf64884bff29c8b6ff6021dc27f5

doc: ncu-team sync update Fixes: https://github.com/nodejs/Release/issues/565

view details

Myles Borins

commit sha 9e98cce6d22bc7c41a6498f15f1385c3cb6eeb69

Merge pull request #581 from BethGriggs/lts-team-update doc: ncu-team sync update

view details

push time in 6 days

PR merged nodejs/Release

doc: ncu-team sync update

Fixes: https://github.com/nodejs/Release/issues/565

Nomination has been open a while

+1 -0

0 comment

1 changed file

BethGriggs

pr closed time in 6 days

issue closednodejs/Release

Nominating @BridgeAR for LTS team

I think this is overdue, it'd be great to have @BridgeAR on board to be able to help out with future LTS releases

closed time in 6 days

BethGriggs

issue commentnodejs/TSC

Node.js Technical Steering Committee (TSC) Meeting 2020-05-21

Nothing new to add for modules this week

mhdawson

comment created time in 6 days

issue commentnodejs/Release

"Current" should include v12.13

@ljharb I don't see anything specific or actionable. I am personally -1 to the idea of having a release be current and LTS at the same time.

Do you have an actionable suggestion to avoid the edge case you are concerned about?

ljharb

comment created time in 6 days

Pull request review commentromejs/rome

Add governance document

 # Contributor Covenant Code of Conduct +**Instances of abusive, harassing, or otherwise unacceptable behavior may be+reported to the community leaders responsible for enforcement at+<conduct@romejs.dev>.**++The following people have access to the above email address:++ - Sebastian McKenzie <sebmck@gmail.com> [GitHub](https://github.com/sebmck) [Twitter](https://twitter.com/sebmck)++In the event that your report includes one of the people mentioned above please+feel free to reach out to one of the other people listed instead.++The moderation process for violations is listed in [`MODERATION.md`](./MODERATION.md).

I just don't think the public call out like that has any sort of positive outcome.

sebmck

comment created time in 6 days

Pull request review commentromejs/rome

Add governance document

+# Governance++This document outlines the governance model for Rome. This includes the contributor model, code review, merging, and the consequences and process for Code of Conduct violations.++## Member Roles++All members must follow the [Code of Conduct](CODE_OF_CONDUCT.md). Consequences for member violations are detailed in [Moderation](#moderation).++### Core Contributor++Core Contributors are those who have a history of consistent contributions, whether this pull requests, project management, or support.++There are no expectations around activity. There may be a time where contributor privileges are restricted or removed for inactivity. Once core contributor status has been granted you will not lose org membership.++New contributors will be decided based on a unanimous vote by the existing core contributors.

If you plan to do a unanimous vote here this could likely be replaced with consensus seeking. E.g. set timeframe and no objections. If you require every contributor to vote to do this you could end up getting stalled waiting for all the votes to get in.

Would you be open to self nomination? If so might be a good idea to document

sebmck

comment created time in 6 days

Pull request review commentromejs/rome

Add governance document

+# Governance++This document outlines the governance model for Rome. This includes the contributor model, code review, merging, and the consequences and process for Code of Conduct violations.++## Member Roles++All members must follow the [Code of Conduct](CODE_OF_CONDUCT.md). Consequences for member violations are detailed in [Moderation](#moderation).++### Core Contributor++Core Contributors include anyone with a history of consistent contributions, including but not limited to pull requests, project management, or support.++There are no expectations around activity. There may be a time where contributor privileges are restricted or removed for inactivity. Once core contributor status has been granted you will not lose org membership.++New core contributors will be added based on a unanimous vote by the existing core contributors.++### Manager++Managers have additional privileges over core contributors. Managers control and maintain sensitive project assets, and act as tiebreakers in the event of disagreements. These additional privileges include:++- Access to the [@romejsdev Twitter account](https://twitter.com/romejsdev)+- Administration privileges on the [Rome GitHub org](https://github.com/romejs)+- Administration privileges on the [Rome Discord server](https://github.com/romejs)+- Publish access to the [`rome` npm package](https://www.npmjs.com/package/rome)+- Domain registrar and DNS access to all `romejs.*` domains+- Administration access to the `romejs.dev` Netlify account+- Ability to decide on moderation decisions involving core contributors+- Access to the `*@romejs.dev` email address++New managers will be added based on a unanimous vote by the existing managers.++### Owner++Certain parts of the codebase can be owned by one or more people. This process is informal and inclusion could be a result of substantial contribution or delegation by other members. It's the responsibility of a core contributor to identify the relevant owners and ensure there's an understanding when it comes to code review.++## Current Members++Members listed in alphabetical order.++### Managers++- [Sebastian McKenzie @sebmck](https://github.com/sebmck)++### Core Contributors++- [Eduardo Lopes @EduardoLopes](https://github.com/EduardoLopes)+- [Florent Cailhol @ooflorent](https://github.com/ooflorent)+- [Jamie Kyle @jamiebuilds](https://github.com/jamiebuilds)+- [Kevin Kelbie](https://github.com/KevinKelbie)+- [Olivier Dusabimana @diokey](https://github.com/diokey)+- [Paul Bouchon @bitpshr](https://github.com/bitpshr)+- [Victor Hom @VictorHom](https://github.com/VictorHom)++## Code review and merging++- All code needs to go through Pull Requests (PR) and must pass status checks before being merged. If a PR is merged that breaks `master` due to the branch not being up to date, then it should either be reverted or a quick fix merged as a separate PR.+- If a PR is against code that you have previously committed and is either small changes, bug fixes, or refactors, then you're free to merge it without any review. However if you don't feel confident in your changes then you can wait for approval from another core contributor.+- If you are an owner of a particular area you are free to merge it without any review despite PR size.+- If after a PR is merged and there are comments or suggestions after the fact, allow yourself time to address them in a follow up PR. If you don't think you will be able to respond in a reasonable timeframe then create an issue to track.+- If necessary, identify potential owners for PR review and approval.+- Ensure that PR summary is detailed listing steps you took to verify, the rationale, and relevant issues and people involved in any prior discussion.+- Ensure that PRs contain adequate tests and code comments for a future contributor to derive intent and modify the code safely.+- You are welcome to use the `rome` repo for your WIP branches. However you should prefix branches with your username. ie. `git branch sebmck/feature`. Branches not involved in an active PR will be regularly pruned.+- If you are adding a new feature then ensure that it has been discussed or approved on GitHub or Discord.++## Moderation++Users found to be in violation of the projects [Code of Conduct](./CODE_OF_CONDUCT.md) will be:++- Banned from the GitHub org and Discord server+- Have their contributor status revoked (if applicable)+- Have manager privileges revoked (if applicable)+- Action listed in [`MODERATION.md`](./MODERATION.md). There may be some scenarios where discretion is required and some details omitted to protect and individual's privacy.++This is a one-strike policy.++Code of Conduct violations can be reported to <conduct@romejs.dev> which is listed in the [Code of Conduct](./CODE_OF_CONDUCT.md). This email address is monitored by managers. Alternatively email addresses for each manager is included in the Code of Conduct for private disclosements in the event of a report involving a manager.++Moderation decisions and Code of Conduct violations will be reviewed by the managers in private. If a violation involves a manager then it will be decided amongst the remaining managers. Review can be delegated to core contributors.++## OpenCollective fund allocation++- Usage of funds has yet to be decided.

Do you have things you definitely don't want to use it for? Might be good spelling out anti-goals early

sebmck

comment created time in 6 days

Pull request review commentromejs/rome

Add governance document

+# Governance++This document outlines the governance model for Rome. This includes the contributor model, code review, merging, and the consequences and process for Code of Conduct violations.++## Member Roles++All members must follow the [Code of Conduct](CODE_OF_CONDUCT.md). Consequences for member violations are detailed in [Moderation](#moderation).++### Core Contributor++Core Contributors include anyone with a history of consistent contributions, including but not limited to pull requests, project management, or support.++There are no expectations around activity. There may be a time where contributor privileges are restricted or removed for inactivity. Once core contributor status has been granted you will not lose org membership.++New core contributors will be added based on a unanimous vote by the existing core contributors.++### Manager++Managers have additional privileges over core contributors. Managers control and maintain sensitive project assets, and act as tiebreakers in the event of disagreements. These additional privileges include:++- Access to the [@romejsdev Twitter account](https://twitter.com/romejsdev)+- Administration privileges on the [Rome GitHub org](https://github.com/romejs)+- Administration privileges on the [Rome Discord server](https://github.com/romejs)+- Publish access to the [`rome` npm package](https://www.npmjs.com/package/rome)+- Domain registrar and DNS access to all `romejs.*` domains+- Administration access to the `romejs.dev` Netlify account+- Ability to decide on moderation decisions involving core contributors+- Access to the `*@romejs.dev` email address++New managers will be added based on a unanimous vote by the existing managers.++### Owner++Certain parts of the codebase can be owned by one or more people. This process is informal and inclusion could be a result of substantial contribution or delegation by other members. It's the responsibility of a core contributor to identify the relevant owners and ensure there's an understanding when it comes to code review.++## Current Members++Members listed in alphabetical order.++### Managers++- [Sebastian McKenzie @sebmck](https://github.com/sebmck)++### Core Contributors++- [Eduardo Lopes @EduardoLopes](https://github.com/EduardoLopes)+- [Florent Cailhol @ooflorent](https://github.com/ooflorent)+- [Jamie Kyle @jamiebuilds](https://github.com/jamiebuilds)+- [Kevin Kelbie](https://github.com/KevinKelbie)+- [Olivier Dusabimana @diokey](https://github.com/diokey)+- [Paul Bouchon @bitpshr](https://github.com/bitpshr)+- [Victor Hom @VictorHom](https://github.com/VictorHom)++## Code review and merging++- All code needs to go through Pull Requests (PR) and must pass status checks before being merged. If a PR is merged that breaks `master` due to the branch not being up to date, then it should either be reverted or a quick fix merged as a separate PR.+- If a PR is against code that you have previously committed and is either small changes, bug fixes, or refactors, then you're free to merge it without any review. However if you don't feel confident in your changes then you can wait for approval from another core contributor.+- If you are an owner of a particular area you are free to merge it without any review despite PR size.+- If after a PR is merged and there are comments or suggestions after the fact, allow yourself time to address them in a follow up PR. If you don't think you will be able to respond in a reasonable timeframe then create an issue to track.+- If necessary, identify potential owners for PR review and approval.+- Ensure that PR summary is detailed listing steps you took to verify, the rationale, and relevant issues and people involved in any prior discussion.+- Ensure that PRs contain adequate tests and code comments for a future contributor to derive intent and modify the code safely.+- You are welcome to use the `rome` repo for your WIP branches. However you should prefix branches with your username. ie. `git branch sebmck/feature`. Branches not involved in an active PR will be regularly pruned.+- If you are adding a new feature then ensure that it has been discussed or approved on GitHub or Discord.++## Moderation++Users found to be in violation of the projects [Code of Conduct](./CODE_OF_CONDUCT.md) will be:++- Banned from the GitHub org and Discord server+- Have their contributor status revoked (if applicable)+- Have manager privileges revoked (if applicable)+- Action listed in [`MODERATION.md`](./MODERATION.md). There may be some scenarios where discretion is required and some details omitted to protect and individual's privacy.++This is a one-strike policy.++Code of Conduct violations can be reported to <conduct@romejs.dev> which is listed in the [Code of Conduct](./CODE_OF_CONDUCT.md). This email address is monitored by managers. Alternatively email addresses for each manager is included in the Code of Conduct for private disclosements in the event of a report involving a manager.++Moderation decisions and Code of Conduct violations will be reviewed by the managers in private. If a violation involves a manager then it will be decided amongst the remaining managers. Review can be delegated to core contributors.++## OpenCollective fund allocation++- Usage of funds has yet to be decided.++## Governance changes++- Future changes to this document will require approval from all core contributors.

Above you mention voting, here you state approval. I think it would be a good idea to pick a consensus model and document it. For changes to governance it is usually good to have a slightly larger timebox for changes.

sebmck

comment created time in 6 days

Pull request review commentromejs/rome

Add governance document

+# Governance++This document outlines the governance model for Rome. This includes the contributor model, code review, merging, and the consequences and process for Code of Conduct violations.++## Member Roles++All members must follow the [Code of Conduct](CODE_OF_CONDUCT.md). Consequences for member violations are detailed in [Moderation](#moderation).++### Core Contributor++Core Contributors include anyone with a history of consistent contributions, including but not limited to pull requests, project management, or support.++There are no expectations around activity. There may be a time where contributor privileges are restricted or removed for inactivity. Once core contributor status has been granted you will not lose org membership.++New core contributors will be added based on a unanimous vote by the existing core contributors.++### Manager++Managers have additional privileges over core contributors. Managers control and maintain sensitive project assets, and act as tiebreakers in the event of disagreements. These additional privileges include:++- Access to the [@romejsdev Twitter account](https://twitter.com/romejsdev)+- Administration privileges on the [Rome GitHub org](https://github.com/romejs)+- Administration privileges on the [Rome Discord server](https://github.com/romejs)+- Publish access to the [`rome` npm package](https://www.npmjs.com/package/rome)+- Domain registrar and DNS access to all `romejs.*` domains+- Administration access to the `romejs.dev` Netlify account+- Ability to decide on moderation decisions involving core contributors+- Access to the `*@romejs.dev` email address++New managers will be added based on a unanimous vote by the existing managers.++### Owner++Certain parts of the codebase can be owned by one or more people. This process is informal and inclusion could be a result of substantial contribution or delegation by other members. It's the responsibility of a core contributor to identify the relevant owners and ensure there's an understanding when it comes to code review.++## Current Members++Members listed in alphabetical order.++### Managers++- [Sebastian McKenzie @sebmck](https://github.com/sebmck)++### Core Contributors++- [Eduardo Lopes @EduardoLopes](https://github.com/EduardoLopes)+- [Florent Cailhol @ooflorent](https://github.com/ooflorent)+- [Jamie Kyle @jamiebuilds](https://github.com/jamiebuilds)+- [Kevin Kelbie](https://github.com/KevinKelbie)+- [Olivier Dusabimana @diokey](https://github.com/diokey)+- [Paul Bouchon @bitpshr](https://github.com/bitpshr)+- [Victor Hom @VictorHom](https://github.com/VictorHom)++## Code review and merging++- All code needs to go through Pull Requests (PR) and must pass status checks before being merged. If a PR is merged that breaks `master` due to the branch not being up to date, then it should either be reverted or a quick fix merged as a separate PR.+- If a PR is against code that you have previously committed and is either small changes, bug fixes, or refactors, then you're free to merge it without any review. However if you don't feel confident in your changes then you can wait for approval from another core contributor.

I can see why you want to have this here but I very much am not a fan of not requiring review. Even a single reviewer help ensure that there is buyin and folks are not just pushing code that has 0 consensus around it

sebmck

comment created time in 6 days

Pull request review commentromejs/rome

Add governance document

+# Governance++This document outlines the governance model for Rome. This includes the contributor model, code review, merging, and the consequences and process for Code of Conduct violations.++## Member Roles++All members must follow the [Code of Conduct](CODE_OF_CONDUCT.md). Consequences for member violations are detailed in [Moderation](#moderation).++### Core Contributor++Core Contributors include anyone with a history of consistent contributions, including but not limited to pull requests, project management, or support.++There are no expectations around activity. There may be a time where contributor privileges are restricted or removed for inactivity. Once core contributor status has been granted you will not lose org membership.++New core contributors will be added based on a unanimous vote by the existing core contributors.

If you are planning a unanimous vote here you might want to switch to consensus seeking... e.g. set time frame and no objections. Requiring a vote with all members having to vote can create serious friction if even a single person is not available. If the intent is "no objections" framing it that was might be more appropriate.

Also, would you be open to self nomination?

sebmck

comment created time in 6 days

Pull request review commentromejs/rome

Add governance document

+# Governance++This document outlines the governance model for Rome. This includes the contributor model, code review, merging, and the consequences and process for Code of Conduct violations.++## Member Roles++All members must follow the [Code of Conduct](CODE_OF_CONDUCT.md). Consequences for member violations are detailed in [Moderation](#moderation).++### Core Contributor++Core Contributors include anyone with a history of consistent contributions, including but not limited to pull requests, project management, or support.++There are no expectations around activity. There may be a time where contributor privileges are restricted or removed for inactivity. Once core contributor status has been granted you will not lose org membership.++New core contributors will be added based on a unanimous vote by the existing core contributors.++### Manager++Managers have additional privileges over core contributors. Managers control and maintain sensitive project assets, and act as tiebreakers in the event of disagreements. These additional privileges include:++- Access to the [@romejsdev Twitter account](https://twitter.com/romejsdev)+- Administration privileges on the [Rome GitHub org](https://github.com/romejs)+- Administration privileges on the [Rome Discord server](https://github.com/romejs)+- Publish access to the [`rome` npm package](https://www.npmjs.com/package/rome)+- Domain registrar and DNS access to all `romejs.*` domains+- Administration access to the `romejs.dev` Netlify account+- Ability to decide on moderation decisions involving core contributors+- Access to the `*@romejs.dev` email address++New managers will be added based on a unanimous vote by the existing managers.

Sam as above regarding unanimous vote vs. consensus seeking. But in this case, since there are likely very few managers, it may not be an issue. Although a manager being out on vacation or leave could in theory completely block this process based on current goernance.

sebmck

comment created time in 6 days

Pull request review commentromejs/rome

Add governance document

 # Contributor Covenant Code of Conduct +**Instances of abusive, harassing, or otherwise unacceptable behavior may be+reported to the community leaders responsible for enforcement at+<conduct@romejs.dev>.**++The following people have access to the above email address:++ - Sebastian McKenzie <sebmck@gmail.com> [GitHub](https://github.com/sebmck) [Twitter](https://twitter.com/sebmck)++In the event that your report includes one of the people mentioned above please+feel free to reach out to one of the other people listed instead.++The moderation process for violations is listed in [`MODERATION.md`](./MODERATION.md).

I have serious mixed feelings about making this list public.

Are you planning for them to be anonymized? Having a public "name + shame" list seems like a recipe for a bad time. For Node.js we have a private moderation repo where we have un anonymized information that is available to all collaborators across the org, but any public facing content is scrubbed.

sebmck

comment created time in 6 days

Pull request review commentromejs/rome

Add governance document

+# Governance++This document outlines the governance model for Rome. This includes the contributor model, code review, merging, and the consequences and process for code of conduct violations.++## Member Roles++All members must follow the [code of conduct](https://github.com/romejs/rome/blob/master/.github/CODE_OF_CONDUCT.md). Consequences for member violations are detailed in [Moderation](#moderation).++### Core Contributor++Core Contributors are those who have proved themselves as an active contributor by being involved in project management or by submitting high quality pull requests.++There are no expectations around activity. There may be a time where contributor privileges are restricted or removed for inactivity. However you will not lose org membership.++New contributors will be decided based on a general consensus by the existing core contributors.

Probably a good idea to document the consensus seeking process in here.

Is it a vote? Consensus seeking? Rough consensus? Meeting based?

sebmck

comment created time in 6 days

Pull request review commentromejs/rome

Add governance document

 # Contributor Covenant Code of Conduct +**Instances of abusive, harassing, or otherwise unacceptable behavior may be+reported to the community leaders responsible for enforcement at+<conduct@romejs.dev>.**++The following people have access to the above email address:++ - Sebastian McKenzie <sebmck@gmail.com> [GitHub](https://github.com/sebmck) [Twitter](https://twitter.com/sebmck)++In the event that your report includes one of the people mentioned above please

Probably a good idea to get a second person on this list before landing this so that this clause can actually be followed.

sebmck

comment created time in 6 days

Pull request review commentromejs/rome

Add core contributor governance document

+# Governance++Rome is still an early project. This document serves as rough guidelines for merging code and decision making for core contributors. Core contributors are those who have been added to the Rome org and have triage and push privileges. This document is not intended to be strict and these rules will evolve over time.++These rules are loose and intend to give core contributors autonomy and discretion. Code can be easily reverted and we should value rapid change and refactoring that would otherwise be tedious and bureaucratic.++## What is a core contributor?++- Someone who has proved themselves as an active contributor by being involved in project management or by submitting high quality pull requests.+- There is no hard constraints. As the project evolves the bar for inclusion may be raised.+- New contributors will be decided based on a general consensus by the existing core contributors.++## Expectations++- Follow the [code of conduct](https://github.com/romejs/rome/blob/master/.github/CODE_OF_CONDUCT.md). Violations will result in your contributor status being revoked.+- Don't abuse your repo access to push malicious code, or to edit or delete other peoples comments outside of moderation.+- There are no expectations around activity. There may be a time where contributor privileges are restricted for inactivity. However you will not lose org membership.++## Code review and merging++- All code needs to go through pull requests and must pass status checks before being merged. If a PR is merged that breaks `master` due to conflicts then submit a new PR to fix it.

also something that breaks master could be reverted rather than fixed 😇

sebmck

comment created time in 6 days

Pull request review commentromejs/rome

Add core contributor governance document

+# Governance++Rome is still an early project. This document serves as rough guidelines for merging code and decision making for core contributors. Core contributors are those who have been added to the Rome org and have triage and push privileges. This document is not intended to be strict and these rules will evolve over time.++These rules are loose and intend to give core contributors autonomy and discretion. Code can be easily reverted and we should value rapid change and refactoring that would otherwise be tedious and bureaucratic.++## What is a core contributor?++- Someone who has proved themselves as an active contributor by being involved in project management or by submitting high quality pull requests.+- There is no hard constraints. As the project evolves the bar for inclusion may be raised.+- New contributors will be decided based on a general consensus by the existing core contributors.++## Expectations++- Follow the [code of conduct](https://github.com/romejs/rome/blob/master/.github/CODE_OF_CONDUCT.md). Violations will result in your contributor status being revoked.+- Don't abuse your repo access to push malicious code, or to edit or delete other peoples comments outside of moderation.+- There are no expectations around activity. There may be a time where contributor privileges are restricted for inactivity. However you will not lose org membership.++## Code review and merging++- All code needs to go through pull requests and must pass status checks before being merged. If a PR is merged that breaks `master` due to conflicts then submit a new PR to fix it.+- If a PR is against code that you have previously committed and is either small changes, bug fixes, or refactors, then you're free to merge it without any review. However if you don't feel confident in your changes then wait for approval from another core contributor.+- If you have shown yourself to be an owner of a particular area, whether it's by substantial contribution or prior discussion, you are free to merge it without any review despite PR size.+- Make sure you have a consensus on changes. If you are adding a new feature then ensure that it has been discussed or approved on GitHub or Discord.

Ensuring consensus seems to go against the above rules not requiring sign off.

Obviously this will be a function of how many active collaborators you have and you don't want to create a bottleneck... but allowing people to carte blanche land PRs without review for areas they "own" doesn't seem inline with requiring consensus... unless you need to only build consensus between owners

sebmck

comment created time in 6 days

Pull request review commentromejs/rome

Add core contributor governance document

+# Governance++Rome is still an early project. This document serves as rough guidelines for merging code and decision making for core contributors. Core contributors are those who have been added to the Rome org and have triage and push privileges. This document is not intended to be strict and these rules will evolve over time.++These rules are loose and intend to give core contributors autonomy and discretion. Code can be easily reverted and we should value rapid change and refactoring that would otherwise be tedious and bureaucratic.++## What is a core contributor?++- Someone who has proved themselves as an active contributor by being involved in project management or by submitting high quality pull requests.+- There is no hard constraints. As the project evolves the bar for inclusion may be raised.+- New contributors will be decided based on a general consensus by the existing core contributors.++## Expectations++- Follow the [code of conduct](https://github.com/romejs/rome/blob/master/.github/CODE_OF_CONDUCT.md). Violations will result in your contributor status being revoked.+- Don't abuse your repo access to push malicious code, or to edit or delete other peoples comments outside of moderation.+- There are no expectations around activity. There may be a time where contributor privileges are restricted for inactivity. However you will not lose org membership.++## Code review and merging++- All code needs to go through pull requests and must pass status checks before being merged. If a PR is merged that breaks `master` due to conflicts then submit a new PR to fix it.

or revert?

Some of this stuff around "best practices" might be better fit in a CONTRIBUTING.md at some point. I know I know... I'm repeating myself...

When you can land code ✅ How to land it and what to do when it's broken ❌

sebmck

comment created time in 6 days

Pull request review commentromejs/rome

Add core contributor governance document

+# Governance++Rome is still an early project. This document serves as rough guidelines for merging code and decision making for core contributors. Core contributors are those who have been added to the Rome org and have triage and push privileges. This document is not intended to be strict and these rules will evolve over time.++These rules are loose and intend to give core contributors autonomy and discretion. Code can be easily reverted and we should value rapid change and refactoring that would otherwise be tedious and bureaucratic.++## What is a core contributor?++- Someone who has proved themselves as an active contributor by being involved in project management or by submitting high quality pull requests.+- There is no hard constraints. As the project evolves the bar for inclusion may be raised.+- New contributors will be decided based on a general consensus by the existing core contributors.++## Expectations++- Follow the [code of conduct](https://github.com/romejs/rome/blob/master/.github/CODE_OF_CONDUCT.md). Violations will result in your contributor status being revoked.+- Don't abuse your repo access to push malicious code, or to edit or delete other peoples comments outside of moderation.

TBH these kinds of specific rules might be better in moderation guidelines rather than the governance. Governance documents can get large fast, especially as more process gets introduced.

Rules around how to remove someone ✅ All the reasons to remove them ❌

sebmck

comment created time in 6 days

Pull request review commentromejs/rome

Add core contributor governance document

+# Governance++Rome is still an early project. This document serves as rough guidelines for merging code and decision making for core contributors. Core contributors are those who have been added to the Rome org and have triage and push privileges. This document is not intended to be strict and these rules will evolve over time.++These rules are loose and intend to give core contributors autonomy and discretion. Code can be easily reverted and we should value rapid change and refactoring that would otherwise be tedious and bureaucratic.++## What is a core contributor?++- Someone who has proved themselves as an active contributor by being involved in project management or by submitting high quality pull requests.

You can scale infinitely if you use consensus-seeking

Call for objections, minimal amount of review. This is what Node.js does. 1 - 2 signoff needed and 48 hours. Trust collaborators to do the right thing. Sometimes is doesn't work, but in 5 years that has happened very rarely.

FWIW I have very mixed feelings for "open open source"... e.g. give everyone the bit asap. Especially when we are talking about general supply chain security. I do think being a bit more liberal with permissions is good, but striking a balance is hard.

sebmck

comment created time in 6 days

issue commentwhatwg/html

Proposal: import.meta.resolveURL

@domenic I'll approach it from that perspective then.

guybedford

comment created time in 7 days

issue commentwhatwg/html

Proposal: import.meta.resolveURL

@domenic there are a number of reasons that we are interested in having import.meta.resolve() be an async API in node.js core. I have to do a bit more research to put together a list of reasons but if they are compelling enough would you be open to exploring async? Keeping these APIs consistent across hosts would is a big priority for myself and the Node.js modules team.

guybedford

comment created time in 7 days

push eventtc39/proposal-module-attributes

ghpages auto deploy

commit sha d02ce3ac7132424ed32da924a31fe81f5367c7ca

Automated deployment: Wed May 20 21:28:33 UTC 2020 9a137ef234b198ce2ffeab79e711709fa2893797

view details

push time in 7 days

issue commentnodejs/node

Broken support for Top-Level Await

We could also catch the TLA error in the CJS goal and give a better error message

sla100

comment created time in 7 days

issue commentnodejs/node

Broken support for Top-Level Await

I'm trying to figure out if there is something actionable here. Do we need to update docs or changelog? Should we close this?

sla100

comment created time in 7 days

issue commentwhatwg/html

Proposal: import.meta.resolveURL

We've implemented something similar to this API in Node.js already and are discussing if we should potentially unflag it.

https://github.com/nodejs/node/pull/33464

Is WHATWG still interested in exploring this API? If so I would personally like to ensure that we keep something consistent between Node.js and what browsers would implement.

guybedford

comment created time in 7 days

pull request commentnodejs/node

esm: unflag import.meta.resolve

Has there been any signal from upstream that a standardized version of this is ready to land in browsers? I'm uncomfortable unflagging this until that point.

While we do have TLA, it is still behind a flag... this to me seems premature

guybedford

comment created time in 7 days

push eventnodejs/nodejs.dev

Myles Borins

commit sha 4d2bfb4789aaca274d356cfa985932075bdee55f

tools: remove husky (#733) Dual typescript in deps / devDeps was also breaking `npm ci` so I've fixed that in the package.json Fixes: https://github.com/nodejs/nodejs.dev/issues/745

view details

push time in 7 days

issue closednodejs/nodejs.dev

Two different versions of TypeScript

Description

warning package.json: "dependencies" has dependency "typescript" with range "^3.8.3" that collides with a dependency in "devDependencies" of the same name with version "3.9.2" $ gatsby develop

ERROR

Steps to reproduce

Clone the repo and yarn in it and then yarn start

<!-- Clear steps describing how to reproduce the issue. -->

Environment

  • OS Version: macOS
  • Browser Version: Chrome

closed time in 7 days

ahmadawais

PR merged nodejs/nodejs.dev

tools: remove husky

This seems to have regressed after we landed staging into master

Refs: https://github.com/nodejs/nodejs.dev/issues/735

<!-- Please read the Code of Conduct and the Contributing Guidelines before opening a pull request. -->

Description

<!-- Write a brief description of the changes introduced by this PR -->

Related Issues

<!-- Link to the issue that is fixed by this PR (if there is one) e.g. Fixes #1234, Addresses #1234, Related to #1234, etc. -->

<!-- If you want to generate a preview of this PR on our staging server please make a comment on the Pull-Request with the text /preview -->

+1134 -2304

6 comments

3 changed files

MylesBorins

pr closed time in 7 days

pull request commentnodejs/nodejs.dev

tools: remove husky

@alexandrtovmach protecting those folders seems like a great idea, but also something that doesn't require linting the commit messages to accomplish. Would you be open to removing your block on this PR and opening a new issue to discuss how we can accomplish this? I think it would be prudent to do it the same way across repos... so if commit linting is how we do it then I'd be more open to it... but I'm still not convinced we neet to lint the commit title + message content... which is what I originally had issue with husky around.

MylesBorins

comment created time in 7 days

pull request commentnodejs/nodejs.dev

tools: remove husky

@saulonunesdev PTAL I've updated the package-lock.json and also removed the commit lint dependencies that are no longer being used

The PR was failing npm ci due to the double Typescript dependencies so I've fixed that as part of this PR as well. Currently it is done in a single commit but can break it out into two.

@alexandrtovmach I've thought a bit about the commit linting stuff... if we really want to enforce commit linting I think it would be better to do it as a CI job and something that is fixed prior to landing, this is how we do it in node.js core. Enforcing it before pushing creates a ton of friction imho that really isn't worth it for the scope of this project.

MylesBorins

comment created time in 7 days

push eventMylesBorins/nodejs.dev

Myles Borins

commit sha b325ff07a15e924674c0e395e4e7833e6d7dbaf5

tools: remove husky Dual typescript in deps / devDeps was also breaking `npm ci` so I've fixed that in the package.json Fixes: https://github.com/nodejs/nodejs.dev/issues/745

view details

push time in 7 days

push eventMylesBorins/nodejs.dev

Myles Borins

commit sha de67d7098911fa89ce0c3b3535df206d3597e648

tools: remove husky

view details

push time in 7 days

pull request commentnodejs/nodejs.dev

tools: remove husky

@alexandrtovmach while removing husky was partially inspired by the yarn / npm mismatch the PR that gained consensus had a broader reasoning

https://github.com/nodejs/nodejs.dev/pull/323#issue-322196855

Relanding husky as part of merging staging undid that consensus. If we want to bring husky back I think the proper way to do it is to remove it again and open a new PR about bringing it back. To be clear I would be planning to block that PR based on the reasoning I gave in the original PR to remove it. I do not see the value we gain in having linted commit messages for this project as we do not do change logs... it only creates friction for developers (both new and experienced)

MylesBorins

comment created time in 7 days

issue commenttc39/proposal-module-attributes

Access attributes by import.meta?

I think this would depend on the caching model.

If there was an attribute such as "meta" that was part of the key for the cache this could effectively make different instances

On Wed, May 20, 2020, 12:25 PM Jordan Harband notifications@github.com wrote:

B could be imported many times with different metadata, and it’s only evaluated once, the first time. it wouldn’t make much sense to me for it to have access only to the metadata provided by the first importer.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tc39/proposal-module-attributes/issues/58#issuecomment-631582245, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADZYV7XKQOT6FS53UEHH53RSP77ZANCNFSM4NF7ELBA .

Jack-Works

comment created time in 7 days

delete branch nodejs/nodejs.dev

delete branch : add-yarn-as-dev-dep

delete time in 7 days

delete branch nodejs/nodejs.dev

delete branch : MylesBorins-update-deps

delete time in 7 days

delete branch nodejs/nodejs.dev

delete branch : sta

delete time in 7 days

create barnchnodejs/nodejs.dev

branch : sta

created branch time in 7 days

issue commentnodejs/nodejs.dev

Regressions after landing staging

More regressions:

https://github.com/nodejs/nodejs.dev/issues/746

https://github.com/nodejs/nodejs.dev/issues/745

MylesBorins

comment created time in 7 days

issue commentnodejs/node

doc: Explicitly state that package.json is no longer exported when using exports

oops, butter fingers. sorry for the close

ctavan

comment created time in 8 days

IssuesEvent

issue closednodejs/node

doc: Explicitly state that package.json is no longer exported when using exports

📗 API Reference Docs Problem

<!------------------------------------------------------------------------------ Thank you for wanting to make nodejs.org better!

This template is for issues with the Node.js API reference docs.

For more general support, please open an issue in our help repo at “https://github.com/nodejs/help”.

For the issue title, enter a one-line summary after “doc: ”. The “✍️” signifies a request for input. If unsure, do the best you can.

If you found a problem with nodejs.org beyond the API reference docs, please open an issue in our website repo at “https://github.com/nodejs/nodejs.org”. ------------------------------------------------------------------------------->

<!-- Version: output of “node -v” Platform: output of “uname -a” (UNIX), or version and 32 or 64-bit (Windows) Subsystem: if known, please specify affected core module name -->

  • Version: 14.2.0
  • Platform: any
  • Subsystem: esm

Location

Section of the site where the content exists

Affected URL(s):

  • https://nodejs.org/dist/latest-v14.x/docs/api/esm.html

Problem description

Concise explanation of what you found to be problematic

With the introduction of pkg.exports a module only exports the paths explicitly listed in pkg.exports, any other path can no longer be required. Let's have a look at an example:

Node 12.16.3:

> require.resolve('uuid/dist/v1.js');
'/example-project/node_modules/uuid/dist/v1.js'

Node 14.2.0:

> require.resolve('uuid/dist/v1.js');
Uncaught:
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './dist/v1.js' is not defined by "exports" in /example-project/node_modules/uuid/package.json

So far, so good. The docs describe this behavior (although not super prominently):

Now only the defined subpath in "exports" can be imported by a consumer: … While other subpaths will error: …

While this meets the expectations set out by the docs I stumbled upon package.json no longer being exported:

> require.resolve('uuid/package.json');
Uncaught:
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './package.json' is not defined by "exports" in /example-project/node_modules/uuid/package.json

For whatever reason I wasn't assuming the documented rules to apply to package.json itself since I considered it package metadata, not package entrypoints whose visibility a package author would be able to control.

This new behavior creates a couple of issues with tools/bundlers that rely on meta information from package.json.

  • So right now, packages that do contain information to be consumed externally (e.g. by bundlers) in their package.json have to add the package.json to the pkg.exports field.
  • On the other hand bundlers/etc should then handle the case where a dependency doesn't export the package.json gracefully, since it might very well be the fact that a given package doesn't need to export any bundler meta information (and otherwise almost all packages on npm that could ever be used in a react-native project would have to add package.json to their exports).
  • If bundlers however handle a missing package.json exports gracefully, I see the risk that many modules that currently rely on their package.json simply being externally consumable without additional effort might suddenly behave in odd ways when the meta information from package.json is no longer readable by bundlers (and no error is thrown).

Examples where this issue already surfaced:

  • https://github.com/uuidjs/uuid/issues/444
  • https://github.com/sveltejs/rollup-plugin-svelte/issues/104
  • https://github.com/react-native-community/cli/issues/1168
  • https://github.com/ai/nanoevents/issues/44#issuecomment-602010343
  • https://github.com/facebook/react-native/issues/28710
  • https://github.com/locize/i18next-locize-backend/pull/326/files

Now the question is how to move forward with this?

  1. One option would be to keep the current behavior and improve the documentation to explicitly warn about the fact, that package.json can no longer be resolved unless added to exports.
  2. Another option would be to consider adding an exception for package.json and always export it.

I had some discussion on slack with @ljharb and @wesleytodd but we didn't come to an ultimate conclusion yet 🤷‍♂️ .


<!-- Use “[x]” to check the box below if interested in contributing. -->

  • [x] I would like to work on this issue and submit a pull request.

closed time in 8 days

ctavan

issue commentnodejs/node

doc: Explicitly state that package.json is no longer exported when using exports

Haven't had a chance to read everything but wanted to note that package.json not being included in exports is already documented

https://github.com/nodejs/node/blob/master/doc/api/esm.md#package-entry-points

One thing we could do as a start would be make a specialized error message.

ctavan

comment created time in 8 days

push eventMylesBorins/nodejs.dev

T Thiyagaraj

commit sha 2a01daccdabe8363155b4b4c999e0adc0cd1fad2

Install Tabs Styling & Folder Structure Consistency (#742) * style: Update InstallTabs styling * refactor: Remove self-closing divs * refactor: Update snapshots

view details

Myles Borins

commit sha 9161f1d720917cb72a55d099846e05e667f38686

Merge branch 'master' into remove-husky

view details

push time in 8 days

issue openednodejs/nodejs.dev

Learn Sidebar Not working when width between 801 - 1263 pixels

Description

When the width of the browser is between 801 - 1262 the side menu does not work at all. Cannot scroll or click. This is related to the media rule

@media (max-width: 1262px) and (min-width: 800px)

Steps to reproduce

Set width of browser between 801 and 1262 pixels and attempt to click on side menu.

Expected result

The side menu should work

Actual result

The side menu is completely unresponsive

Environment

  • OS Version: MACOS 10.14.6
  • Browser Version: Chrome 81.0.4044.138

Refs: https://github.com/nodejs/nodejs.dev/issues/735

created time in 8 days

issue commentopenjs-foundation/cross-project-council

We should launch the individual membership program

I'd personally appreciate a revisiting from first principles

On Tue, May 19, 2020, 12:52 PM Sara Chipps notifications@github.com wrote:

Raised my hand to help in the last CPC meeting. A question I have for this group is if you are interested in moving forward with the proposal as-is, if there are things that still need to be determined, or if you would prefer to revisit First Principles and start from scratch. Any way it is approached I'd love to be helpful.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openjs-foundation/cross-project-council/issues/551#issuecomment-630946924, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADZYVZLLKLEEXEFM47FVIDRSK2L7ANCNFSM4NEW5DYQ .

eemeli

comment created time in 8 days

issue commentnodejs/nodejs.dev

Regressions after landing staging

Another regression was found with styling

https://github.com/nodejs/nodejs.dev/pull/742

MylesBorins

comment created time in 8 days

pull request commentnodejs/nodejs.dev

Merge staging into master

I'll simplify all of the discussion here by getting to the root of the problem. I blocked the original PR as I did not feel staging was ready to land. That PR was closed in lieu of this one

I did not explicitly block this pr from landing because I trusted the team to follow our consensus seeking process, specifically that I should sign off on this or at least give some sort of signal that I agreed with this landing.

I had 1:1 conversations with more than 1 team member outlining the issues I had.

This PR was landed without those issues resolved and no attempt was made to get my review. This is a violation of the spirit of our collaboration process and undermines the governance of this repo and project.

It is not ok.

I'm not going to push for a reversion as I don't think it will accomplish much, we already fixed the issues with the logo. The concern raised by Tierney about broken links is valid though, and worth looking into.

I've had to rewrite this last paragraph multiple times... But I'm short their experience combined with folks defending their actions rather than remediating has me questioning my continued involvement in the nodejs.dev project, that is really not ok.

benhalverson

comment created time in 9 days

pull request commentnodejs/nodejs.dev

Merge staging into master

@saulonunesdev

See https://github.com/nodejs/nodejs.dev/pull/654#issuecomment-621262218 I explicitly blocked on this an had 1:1 conversations with both Ben and alexandr making it clear that the staging site should not land with those logos.

Digging in heels here is not making the situation better

benhalverson

comment created time in 9 days

pull request commentnodejs/nodejs.dev

Merge staging into master

@benhalverson PayPal and LinkedIn are not members of the foundation and were on the main page. Independent of whether we have a legal sign on on using logos it is extremely poor form to put them on a landing page without giving the companies marketing teams a heads up that they are being included.

I explicitly asked them to be removed in my block on the initial PR and did not think I needed to make it explicit in this PR as I did not expect this to land in the weekend with notice being given on Friday.

I'm going to have to step away from this repo for a couple days because I'm pretty upset tbqh, I feel that my objections were ignored and the consensus process was not followed.

benhalverson

comment created time in 9 days

push eventnodejs/nodejs.dev

Myles Borins

commit sha c279f70eb991cf5a2d07faf8ae34f4e49ade6d0d

docs: Remove hosting page (#736) This was originally removed and regressed when staging merged into master Refs: https://github.com/nodejs/nodejs.dev/issues/735 Refs: https://github.com/nodejs/nodejs.dev/pull/584

view details

push time in 9 days

PR merged nodejs/nodejs.dev

docs: Remove hosting page

This was originally removed and regressed when staging merged into master

Refs: https://github.com/nodejs/nodejs.dev/issues/735 Refs: https://github.com/nodejs/nodejs.dev/pull/584

+0 -96

2 comments

1 changed file

MylesBorins

pr closed time in 9 days

pull request commentnodejs/nodejs.dev

tools: remove husky

We removed husky in October after feedback from multiple individuals that it was making contributing harder

https://github.com/nodejs/nodejs.dev/pull/323

I personally have had to fight with husky more than once, and lost entire commit messages because I didn't include a capitalized first word in the commit message (something we actually lint to not have in the node.js repo). While I appreciate the value of something like conventional commits I don't really think it matters for a repo like nodejs.dev which is a website not a library that requires a changelog. In short I don't think we get significant value out of enforcing commit guidelines for this repo at all and instead create an additional barrier to entry to folks contributing externally. Also afaict this is not enforced if you edit on github nor do we lint for it in CI, so it is currently inconsistent at best.

Further, this was something that was removed via consensus and added back as a regression from staging being merged (prematurely might I add). If we want to add it back we should build group consensus around it being added, not have it be added due to an error.

MylesBorins

comment created time in 9 days

push eventMylesBorins/nodejs.dev

Myles Borins

commit sha f9239442daea91d3ad561646aa6908d10ffdacde

chore: Remove companies from landing page (#732)

view details

Myles Borins

commit sha 20a3bbc58492841fcc12d821b2badf1e0233dcc9

docs: Fix getting started guide (#734) Information is duplicated and stale

view details

Myles Borins

commit sha e0fd0727a13d230e02314f604c2d1a312cf924c1

Merge branch 'master' into remove-husky

view details

push time in 9 days

issue commentnodejs/nodejs.dev

Update CONTRIBUTING

We definitely don't need to get TSC or my own approval to move things forward.

Will come up with an alternative proposal when I'm back in office tomorrow

saulonunesdev

comment created time in 9 days

push eventnodejs/nodejs.dev

Myles Borins

commit sha 20a3bbc58492841fcc12d821b2badf1e0233dcc9

docs: Fix getting started guide (#734) Information is duplicated and stale

view details

push time in 9 days

push eventMylesBorins/nodejs.dev

Myles Borins

commit sha f9239442daea91d3ad561646aa6908d10ffdacde

chore: Remove companies from landing page (#732)

view details

Myles Borins

commit sha 20a3bbc58492841fcc12d821b2badf1e0233dcc9

docs: Fix getting started guide (#734) Information is duplicated and stale

view details

Myles Borins

commit sha dd7b938c2c65ca214b3f3400d38a5cd41cc8bfed

Merge branch 'master' into remove-hosting

view details

push time in 9 days

PR merged nodejs/nodejs.dev

docs: Fix getting started guide

Information is duplicated and stale

+1 -20

1 comment

1 changed file

MylesBorins

pr closed time in 9 days

PR closed nodejs/nodejs.dev

deps: update deps

To replace various dependabot updates

+6085 -9914

2 comments

7 changed files

MylesBorins

pr closed time in 9 days

push eventMylesBorins/nodejs.dev

Myles Borins

commit sha f9239442daea91d3ad561646aa6908d10ffdacde

chore: Remove companies from landing page (#732)

view details

Myles Borins

commit sha edf05d41d95d87dde5913ff3893610d5e63f99c7

Merge branch 'master' into fix-getting-started

view details

push time in 9 days

pull request commentnodejs/nodejs.dev

docs: Remove hosting page

/preview

MylesBorins

comment created time in 9 days

push eventnodejs/nodejs.dev

Myles Borins

commit sha f9239442daea91d3ad561646aa6908d10ffdacde

chore: Remove companies from landing page (#732)

view details

push time in 9 days

PR merged nodejs/nodejs.dev

Reviewers
chore: Remove companies from landing page

This should not have landed when staging was merged into master. Please review asap so we can land

+0 -14

1 comment

1 changed file

MylesBorins

pr closed time in 9 days

pull request commentnodejs/nodejs.dev

Merge staging into master

I went ahead and reviewed the staging merge commit and found 3 regressions and have opened a PR to fix them. This was primarily in build tool + content

https://github.com/nodejs/nodejs.dev/issues/735

I'm unsure if there are similar regressions for styling or gatsby, but I suggest that folks do another review... seeing that there were this many issues across content I'm unconvinced there are not other regressions.... further this is not a great look for how ready this was to land. It does not appear that folks really gave this the level of review they should have for a change of this calibre.

At this point I don't think there is any reason to revert, but I'm going to review our governance and see if we need to implement changes to ensure something like this does not happen again.

benhalverson

comment created time in 9 days

pull request commentnodejs/nodejs.dev

docs: Fix getting started guide

Refs: https://github.com/nodejs/nodejs.dev/issues/735

MylesBorins

comment created time in 9 days

pull request commentnodejs/nodejs.dev

chore: Remove companies from landing page

/cc @nodejs/website-redesign please review this ASAP

MylesBorins

comment created time in 9 days

more