add meeting notes for 2021-01-06

meetings/2021-01-06.md

@@ -0,0 +1,46 @@
+#### Meeting from: January 6th, 2021
+
+# Open RFC Meeting (npm)
+
+### Attendees
+- Darcy Clarke (@darcyclarke)
+- Isaac Z. Schlueter (@isaacs)
+- Christian Siebmanns (@christian24)
+- Nathan LaFreniere (@nlf)
+- Michael Garvin (@wraithgar)
+- Jordan Harband (@ljharb)
+- Wes Todd (@wesleytodd)
+
+### Agenda
+1. **Housekeeping**
+    1. Introduction(s)
+    1. Code of Conduct Acknowledgement
+    1. Outline Intentions & Desired Outcomes
+    1. Announcements
+1. **Issue**: [#301 [RRFC] Workspaces: support to version specifiers other than semver ranges](https://github.com/npm/rfcs/issues/301) - @ruyadorno
+1. **PR**: [Adding `foregroundScripts` option to `Arborist`](https://github.com/npm/arborist/pull/198) - @isaacs
+
+### Notes
+
+#### **Issue**: [#301 [RRFC] Workspaces: support to version specifiers other than semver ranges](https://github.com/npm/rfcs/issues/301) - @ruyadorno
+  - @ruyadorno workspaces only supports semver but could & should be able to support things like a git specifier
+  - @jsg2021 context is pseudo-mono repo
+  - @ljharb what happens with a workspace semver range today? 
+  - @isaacs workspaces work like linked deps
+  - @ljharb belive that workspaces & hoisting models are sort of broken by default (end goal should be defining shared vs. not-shared dependencies)
+  - @ljharb should do a deep-dive without any prior art
+  - @wesleytodd this is similar to work done, & the prior art, with import maps & the current strategy has many issues/edge cases that we need to continue to support/deal with
+  - @isaacs can we create a set of fixtures/tests that define all the use/edge cases & build to that spec
+  - @isaacs sounds like this would be a separate RFC to what this is
+  - @ruyadorno considering what it would look like to symlink everything in place; It's not too late to change how this works
+  - @isaacs two issues we're speaking to seem to be: whether a git repo can be a valid workspace & a more fundamental issue around how we resolve dependency trees 
+  - @isaacs will take away the action to write an RFC for the smaller problem 
+
+#### **PR**: [Adding `foregroundScripts` option to `Arborist`](https://github.com/npm/arborist/pull/198) - @isaacs
+  - @isaacs this brings the old behaivour of npm v6 back/configurable where you do/don't have visible output from scripts
+  - @ljharb should there be some kind of output even when background scripts are running?
+  - @isaacs we do log it currently but just under a loglevel
+  - @ljharb moreso, it would be nice to collapse the output into a single line &/or notify the end-user when any scripts are being run (potentially with status)
+  - @wesleytodd have seen security issues get caught because of indicators coming from run scripts logging
+  - @isaacs don't want to flood output/logs but potentially could introduce better logging/messaging in a debug log/file
+  - @isaacs going to land this as-is for now, potential for improvements on the logging/indicators at the CLI level in the future