---
# System prepended metadata

title: Open RFC Meeting (npm)

---

#### 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
