npm Open RFC, 5 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Open RFC Meeting - Wednesday, May 5th 2021

Description

In our ongoing efforts to better listen to and collaborate with the community, we run an Open RFC call that helps to move conversations and initiatives forward. The focus should be on existing issues/PRs in this repository but can also touch on community/ecosystem-wide subjects.

A

And we're live, uh welcome everyone to another npm, open rc meeting today's date is wednesday. May 5th 2021 will be following along the agenda that was posted. I believe in issue number 374 on the npm rc's repo I've copy and pasted in chat. The meeting notes, talk, feel free to add yourself as an attendee, um and uh I will have to apologize for my internet. I hope it stays up throughout the meeting, but if not, I would ask if somebody could potentially try to record locally. I believe there's a few folks.

A

I can make co-hosts and I'll do that now and yeah we'll be jumping into the agenda here. uh First and foremost, I want to give an acknowledgement uh that these calls, as well as any columns on the rc's forum or sorry, the rfc's repo are covered under code of contact, and these calls we just asked that you be polite and respect when other folks are speaking. Please raise your hand if you have a comment and we'll call on you and yeah just be mindful and thoughtful of others on these calls in terms of announcements.

A

Did anybody have anything they wanted to bring up.

A

Anything going on in the community- I know open.js world is coming up soon for folks that are interested in that I believe myself and potentially I think roy durno as well on our team who's. Not here is going to be joining.

A

I think one of the panels, so the package maintenance working group has a session uh and I think also uh wes uh was wesley todd who's. A part of these calls, often and myself are going to help try to run the first open, js cloud cloud working group. I guess we're calling it cloud collaboration space for package, vulnerability, maintenance, so we've kicked off for repo there. I can share the uh issue, the tracking issue, that we have for, if you'd like to get involved and want to be a part of that call.

A

The sessions are pre-recorded.

A

um So if you do want to be jump on that call- and this will be the uh you know- not inaugural um call for this collaboration space um feel free to add yourself there and we're going to try to figure out a good time to pre-record that session um and that will go on uh as sort of a community focused session for open.js world.

A

And if there's no other announcements.

A

Then we can jump right into the agenda, so the first item that we had here was pr364 restore the mpm6 ability to install one package at a time. I think uh jordan also might have referenced something along these lines.

A

It looks like isaac. You were the last one to follow up here a couple weeks ago. Did you want to maybe speak to this.

B

Yeah I mean I just I saw that the error message and then or the issue rather and when I realized that's how it was behaving uh somebody had been complaining about it in irc as well. um It sort of came out that it was a.

B

B

I don't know if it's not clear to me whether how intentional the change was like, or at least how thought, through the consequences of the change were, even if it were, it was intentional, um like what it what nvm7 currently does makes is defensible right like it. It's basically saying at all times. I want to give you the best possible tree, but I think that it's surprising and like defies expectations.

B

If I ask you to do ask a tool to do one thing, and it does seven other things at the same time and in particular like npm 5, I think, is when it started to auto prune every time you install things and that's super disruptive, especially if you're trying to build up a series.

C

D

B

For development workflows or if you're, trying to manually install things one at a time to test different versions of things or just try things out, and so it like this seems like it goes in more in the worst direction of that of like continue like like it's telling me what my node module should be, and no I'm telling you what my module should be. You need to do what I'm telling you not what you think is best, um so it kind of just feels like it.

B

It feels like a change that may want to be reconsidered.

E

Yeah, so I wouldn't say that it was an intentional change that we always install the entire package tree.

E

It's more, um you know, even if, if you ins, if you tell us to install one thing, we'll actually install everything, it's more, that um it's more a ramification of the or you know outcome of the way that we do add a new package of tree, which is we say, okay. Well, let's add this new dependency from the root package and then do what we do right so um and then just do a reification which is kind of just the simplest way to go about it.

E

The um the thing is now we just recently not too long ago added the ability to install just a single workspace and what this will do so the complexity. If I said, if you say, npm install foo and we only install foo well, foo depends on something and that something is you know also has to be installed somewhere or else the foo you installed doesn't really work and there may be deduplication or other things.

E

We have to account for the fact that you're going to later install something else, and you don't want to have to shuffle more of the package tree than you need to. So um we do still need to build the entire ideal tree and save that to the package json. But as far as what we actually put on disk, we can. We have the capability now to limit it to just a particular sort of branch of the dependency graph.

E

So we can say only install foo and all the things that are needed by foo and all of its dependencies. But nothing else and.

B

Just to clarify, uh if I say, install foo, I would never ever expect that to mean anything except foo.

E

B

E

Right right, and so it might be it might it may end up being that we are, you know, limiting or de-duplicating something based on what else we expect to later put in your package tree. uh So it's not the case, and this. This is something that somebody brought up.

E

uh I think a while ago, it's not the case that npm install foo in a packet in a tree in a project with a package lock is going to be the same guaranteed as npm install foo in an empty project right because if foo has a dependency which could be deduplicated by something else, that's going to be in the tree later we're going to give you that different version. Based on that context, so I mean, I think I think all this like it's too much in the weeds for anybody to really care about.

E

um The fact is, we should just do a filtered reification in those cases. Like that's, that's the proposal, and I don't really see much downside of that. If you, if you do npm install foo and you go well, why isn't bar there and you run npm install cool now everything's, there.

A

Yeah, so this should be possible now with the changes that we made to our burst, um to filter by node right. So um so.

E

Yeah, that's not work space specific from arbor's point of view. It's just you give it a node in the tree and it starts kind of traversing from there.

A

So action on our side, for this would be to queue up the work to actually have update the cly install lib install to call when you the package to essentially call arborist with that uh package that you want to essentially like scope that install to.

E

Yeah so um well, there's two ways we could approach it. One is the the clay could pass in a filter nodes argument like it does, for workspace, installs or um or actually I'm not sure. If that's, I think, arborist just gets a workspaces argument and then it does the filter nodes thing internally. So I would, I would probably suggest that this just be entirely contained within arborist, like if you give it some explicit requests that it'll only reify the changes like if you give it an explicit, add request. It'll only refine those okay, basically.

A

E

As the filter nodes.

A

Okay, so would we be calling this essentially a fix when we ship this? This is it'll, be updated to arborists, but is this essentially like? Would this be a minor, or would this be a patch in terms of the actual change once we actually had this.

E

It's um that's a good question. It it probably the way what I just suggested probably is assembler major on arborist. If we want to do it as a sum for minor, then it would have to be a new field that you can pass into um to reify a new option. You could pass your refi right and the cly would just start doing that.

E

If install gets some arguments.

A

uh Rebecca had a question here um before we jump into the weeds even more just to get action item out of here. um Did you want to say it or you want? uh I can say it on your behalf. If you want.

C

um Sure yeah so with the behavior that isaac's describing sounds the way I remember npm5 behavior working, which is that you ask for a single package, it loads the ideal tree. It adds that dependency and then it does whatever you know additional it does that that one package into the result- and so I I would expect to say that is to say it would- then you know, find all the sub dependencies and so on for that and add them to the new ideal tree and then save that down to your log file.

C

So I guess I'm surprised that the actual user behavior changed it. It sounds like it should be doing essentially the same thing that it was uh now this new thing where it'll only install the like the the filtering thing sounds really cool, uh but is um I think that would fix a npm 5 limitation as well?

C

I guess because it's being reported as a bug in npm 7, I'm wondering what's different.

E

Right so I think I think in npm 6 it would, I guess, what's reported.

A

If you have an update now right, like we're, essentially doing install and then update that.

E

No we're not doing update we're doing a full install with the addition of the new thing you added, rather than only installing the new thing you added. If you have an empty node modules and a package lock json, so.

A

It's like install and then install with that package.

C

Because my understanding of how npm 6 worked is that it added it to the dependency list um first and then it just ran the normal install.

C

It was as if you edited your package json to have that new entry and ran npm, install.

A

So that seems very similar to what we duplicated in terms of yeah.

A

C

Anyway, it sounds like we have a a better solution in the works here that yeah it's just it.

D

C

Pre-Enterprise needs so this may be a moot point. Yeah.

A

Is this? Is this a minor? Is this a? Is this like an improvement or is this? Are we patching the view that we expect.

E

Npm 6 will install everything in your package log. If, if you do npm install foo it installs everything from your package lock.

E

So I don't think I mean did change from v6 or.

B

There's something else to the use case: if that's the actual behavior in v6, then I'm confused, because I I didn't go, try and reproduce this myself, but both the issue and the user in irc seems to be suggesting that npm 6 would not install like that. If I rmrf'd a specific dependency and then I did npm install foo, that specific dependency wouldn't be restored, like necessarily um in npm six, but it would in npm seven.

B

So if, in fact, the behavior is the same, that it literally does act like just an npm install after adding the dependency to package json, then I'm confused why the error was reported, but the filtered behavior still sounds like the correct thing and the better thing for npm to do regardless. Oh.

E

I mean it sounds like a cool feature, but I mean what that what that tends.

E

So if this was the way that npm 6 behaved, which it is not um unless there's some other uh context here that I'm missing, um I just tested it while rebecca was talking, um but uh if npm, 6 and npm 7 are the same, then changing it by default in npm. 7 is a pretty drastic move right, because there's I'm willing to bet that there's somebody out there, depending on the fact that they can just add a new depth and also get all of their other depths right.

E

um It could still be opt-in as a feature, and that seems valuable. I mean this person wants it so there's greater than zero people who would benefit.

B

But yeah, but I would say that if it doesn't, if it didn't do this in npm six and this sort of install everything, behavior were new in npm seven, then I wouldn't expect anyone to be relying on it. Yet, yes, exactly exactly safely considered a bug fix, yeah, okay, uh wes.

A

I see you have your hand up and then car.

F

Okay, hey sorry, I was late. So I'm sorry if this was covered already, but one of the things when I read this originally was that came to mind is the fact that in pm and again I don't know- I don't know if it's six or seven or if there's a difference there, but um I know for sure seven does, because it's been hitting me a bunch lately uh when it does make those other changes to the tree. That includes things like changing links.

F

So like say, you had just recently linked a couple of packages into your local thing and then you added a new dependency. It will go ahead and swap those out for a you know, registry depth um and that's a pretty disruptive workflow.

F

So even if it's not even if it's not just whether there's a difference or not um between npm, six and seven and whether or not this is a feature or a bug that we wanna like address, uh the current workflow is is pretty disruptive uh if you're doing like local package development between a few different packages. So I would like to see this get addressed one way or the other. uh If we make it a flag, you know if it doesn't config like.

F

I would turn it on on everything, because I never want that behavior personally right so like. I would definitely love to see this push forward with obvious changes to the rfc to address the fact that it maybe is inaccurately reported.

A

uh Garth, did you want to top up.

G

Yeah, I'm just reading the rfc here and I want to take a step back and I want to make sure that what we're talking about solves the root problem here right there they're saying what they're, what what they're trying to do is have common depths in a project and then install them into each workspace, um reducing install time and disk usage. I'm just the connection between that and their request is tenuous to me.

G

They're they're, trying to solve this problem this one way and it doesn't work so if they added this, they could solve that problem. That one way but like is this the way to solve that problem.

A

You know yeah, I think isaac noted, and I think I if this is the same person. There was a previous issue talking about like different uh depths, that sets of depths that you could install, and I I think I noted as well. Once we add workspace awareness to npm, install you'll be able to essentially scope. You know, let's say your build or dev or your server uh depth into like a workspace essentially and then be able to essentially have a scope install. So that might be the feedback we give for the specific rfc.

A

If we don't want to change this to as you're saying gar, like kind of like, um oh my goodness, what's the name, what's the word, uh but essentially like bloat or change the actual scope of what they're trying to do. um But it does sound like oh there's, a real rc here that could be made before um filtered node install.

E

Okay, I found the extra bit of context. It is, uh if you do not have a lock file, then npm 6 would not install everything and npm 7 will, if you don't have a lock file, still just build as much as it can based on starting with your your group project.

B

That makes more sense, since I never have a lock file in any of my published packages.

B

That seems like the difference but like so it sound that to me then sounds like we could do a semver patch when no lock file was present to do the filtered approach, but it sounds like it. We wouldn't be able to do that when a lock file is present, because six and seven both did the same thing.

E

It's a it's a bad idea in my opinion, to have npm behave. You know significantly differently if there's a lock file versus if there isn't right in both well.

B

I agree with that. There's a lot of precedent where it doesn't like npm audit.

E

Yeah uh we should be able to audit reified package trees as well, uh just as well as we can audit um or or an ideal tree that has no lock file like yeah. We part of the um one of the one of the somewhat somewhat implicit, somewhat explicit design goals of arborist is that um you know a lock file is a is a helper. um It gets us information about intent and it gets this information about kind of skips skips a big part of the build ideal tree process.

E

But if we don't have a log file, we use whatever information. We have, whether that's a yarn, lock or what's reified on disk or what have you or just the package json.

B

So so, given that as a constraint, which makes sense to me, um then it seems like we should add some sort of flag or configure whatever to allow people to opt into this, whether they have a lock file or not. And then, given that this, that behavior is probably what I think most people would want. Perhaps npm 8 could flip the default of that flag.

E

I'm not sure it is what most people would want, because it's in the in the default with npm 6 is that you get a lock file and the behavior in npm 6 is that if you have a lock file, npm install foo will install everything. So you know I always. I always find it's best to kind of assume that the overwhelming majority of users are doing the default thing right.

B

Right, but I I think it's my assumption would be that they're all running npm install long before they're typing npm install foo, meaning. I think that the users that are actually depending on npm, install foo installing everything like. I can't imagine that anyone's knowingly doing that, even if they all have a lock file. Even if you know well like I think, everyone's installing first and then adding packages after.

E

B

It's I mean it's an unverifiable claim in either direction, but, like that's my intuition, what.

E

Is not an unverifiable claim, though, is that in the default case, if you are, if you have installed with npm six and then you rmrf node modules, and then you npm, install foo, you get all of your dependencies installed sure.

E

So if we change that behavior by as a default, um I'm not sure that most people want this. Like.

B

Yeah I mean we could look into it right and consider changing the default in the future, but, like I, I think that the number of people who rmrf node modules is also very small, so, like I think the default case is not going to include any manual messing with with node modules.

A

So, just to be mindful of time here um it sounds like maybe wes and jordan. You both said that you would potentially use this, and this would be helpful, so 100.

D

A

Maybe either one of you could either recommended men the changes to this rfc or create a new one that explicitly talks. It might be easier to start a new one. That just is like here's a flag that you can pass to install to to stabilize this this behavior or to change it to what you want like inserted in in terms of the filtered node experience right, um filtered node, install experience, yeah.

F

A

E

Start with just.

F

A little discussion in the existing thread just to see you.

E

Know there's a xy problem happening here like let's, let's dig into the actual problem that they're trying to solve, with a single with a filtered install and then uh maybe make a generic like here, is how you can filter your in your reification and expose that to the users that semverminer. That would give jordan and wes and this person that particular tool.

E

uh But there's I wouldn't. I wouldn't just kind of implement, as requested.

A

Exactly uh so, I'm just taking notes.

A

Okay, um so if there's any more feedback or commentary feel free to give or comment on the rc itself, ac moving on uh to issue 363, this is npm.npm ignore include, ignore this is by jordan, essentially well I'll. Let you explain your thoughts on on this issue.

B

Sure um yeah, so I mean the problem, is that although opinions may differ, I find the using the files array uh incredibly dangerous, because I would much rather suffer the consequence of I have to rotate a secret than suffer the consequence of I broke a single user ever by accidentally omitting a file.

B

Thus I use npm ignoring 300 some odd packages that requires me to duplicate, git, ignore and manually, keep them somewhat in sync.

B

Whenever I you know, whenever I make a file system related changes, I have to make sure that they're, either present or absent, as expected in git, ignore an npm ignore like synchronous or together, and uh what would make much more sense to me and be much more simple is if there was some way, I could have a file be effectively a diff on top of git ignore so that if you can cat get ignore and this other contents together, you get npm ignore automatically, because then my better npm ignore file would essentially just always be like git ignore but like negate out the the build output directory.

B

um You know and things of that nature or like negate out the tests. Perhaps things like that? um I am very interested in how doing this backwards compatibly, because my personal use case won't be solved if I have to wait 10 years to to be able to use it exclusively, and I'm aware that there's not a simple implementation solution to do it. So one thing I thought of as a category was: if there's any sort of npm ignore syntax that you could use that would crash an npm version that didn't know how to handle it.

B

Then that syntax is what we could use to put the npm ignore file into better mode, and that way the wrong thing wouldn't happen on older npms. It would just tell you like some error, but I there doesn't appear to be any such syntax and then, similarly, uh an alternative file wouldn't really work, because I'd still then have to have crap npm, ignoring good npm, ignore in all my projects.

B

If I wanted to make sure that the wrong thing didn't happen on an older version of npm, so I don't have a magic solution, but I think it would be a really helpful thing for the ecosystem to be able to provide this functionality. Somehow.

A

Yeah and the current, as far as I remember, the current implementation is, if there's no npm ignore, we actually do fall back to get ignore, which feels.

B

A

Npm, ignore should have extended essentially getting more like those.

B

Yeah like if we had the time machine, I think that's always what it should have done.

E

Well, except that it's a pretty common use case to git, ignore lib and npm, ignore source and then build lib from source.

B

Right but given that negations have always existed in that syntax, I think it would have been pretty straightforward too. Mutations.

E

Negations have not always existed and now syntax, no, it would.

D

E

In npm ignore uh it, it was a long story. Another day.

B

E

I mean yeah, we.

B

Don't have a time machine, so it's irrelevant, but I guess um assuming that git ignores negation syntax. What is originally supported, then that would have been a viable original implementation. I think, but that chip has long since sailed.

B

So um the only idea that other idea I can think of besides syntax, uh you know that crashes old stuff, an alternative file which is not good for the reasons mentioned, uh would be, I suppose, a package.json field, although I don't like the idea of adding one um but like that, still doesn't really help me if I have to still maintain them ignore file. So I'm kind.

E

B

Could create a.

E

You could create a files array where the first entry in files is star and then every other entry is a bang with the things you don't want to include.

B

Does that respect get ignored.

B

E

The whole the whole value is published. Git ignore should always it.

B

Always exists and is always the most important source of truth, and I never. I basically always want to diff off of git ignore yeah. So I never.

E

B

Ignore the git ignore you.

E

Want to npm ignore my git: ignore file ignores plus x y z,.

B

Yes or wait and maybe minus abc yeah.

B

Yeah there's just like like I have. I have never found a use case where I actually want to ignore my get ignore list from scratch, every single time without exception. I always want to start with that minus, maybe one or two things.

H

Is this a place where a uh npm feature polyfill would work where, like we have a tiny script, that people can mpx or npm exec? That does the correct thing and then that that kind of provides that backwards, compatibility, you're, saying new npm would use this or old npm.

B

H

Have so so old npm would have to use that right.

B

If there's a way to force configurably force an old npm to do that, then that might be a viable solution. I don't want to rely on people remembering stuff.

A

So I'm wondering is this like a check that you want to do as well, though, like like how you're saying today the way that you facilitate this? Is you have to like? Keep these things in sync, you have to like um diff. These isn't. If we were to provide to something to you in terms of we've already talked about published prompts before like. If it was like published check like publish validation, then you could like potentially utilize that to write that condition that you could. The problem is that.

B

The I don't know how I could represent the intent of like just in like inject here, the stuff from get ignored right like well. You can modify.

A

The package json from like the git ignore and the mpm ignore you can modify the files array impact the json from those two before you publish.

E

You could also, you could also yeah have a pre-published script that builds your dot npm ignore file, and that could be. You know you could build that with make. You could do anything right right.

B

Yeah and if um that's true so yeah, and if if the end result here is, is that that's what I'd be forced to do then so be it? I may end up doing that, but um it it would seem to it like.

B

Foreign for anyone who isn't who is already using npm ignore who wants a uh an exclude list approach instead of an include list approach um like the current way it works is insufficient, for I think everyone, and what I'm proposing, I think, would be better for everyone in that group.

B

um You know I'm sure this somebody will pop out of the woodwork and say they actually like the current behavior, but, like I, I've still never seen an example so like it's, it would be seemed very unfortunate to me if we ended up concluding that this would be like concretely better in every case, but we can't like, but there's no great way to do it. So do it yourself, even though that might is a viable workaround yeah.

A

uh Gar, you have your hand up.

G

How important is backwards compatibility here I mean because it's during publish right. I would assume you're not publishing with old versions of npm.

B

I I personally do not, but I do not want to assume that somebody else on my project is doing that. So, in fact, I have a pre-published script in all my 300 packages now because I never want to assume someone's using npm, 7 or 6 even and have the wrong thing be published.

G

Okay: well, if this was a feature flag, an additive part, just hey, npm, parse, dnp, more additively right now, it's not back with a compatible and if they're running on npm, then there's issues.

B

But to clarify what I actually want is backwards incompatibility right. I want something that will for loudly fail, older npms, so so normally, what I would want is older stuff to work still. What I actually want is for it to fail so that the wrong thing doesn't happen. It.

H

It I'm it's really weird hearing. Jordan say those words.

E

Oh I've, I've come to expect it. Jordan, jordan, wants everybody else's software to always work.

B

No matter what, in his own, almost never work, that is, that is about right.

E

B

I want every I want the stuff I give to other people to uh to work as well as possible and the stuff I use for myself to be as restricted as possible. You're.

E

You're, greedy with your errors, you you only want crashes on your machine and nowhere else in the world. That's right!.

E

um Yeah, so I think, crashing old and crashing a behavior, that's going to fail on old npms. It's it's going to be on you to just kind of make sure you don't do that right, uh but yeah having having a like gar, said having a flag. That's additive like that, would be really easy, um and then that opens the door to yeah, we'll just put a pragma in dot npm ignore that does that um I, I think. Actually you know just just having it even as like a comment.

E

Syntax like pound bang include dot, get ignore, like that's. Fine and that'll be ignored by old npms. uh So if you install with an old npm it'll, be maybe a you know, half empty package or something or a package that includes all your ignored stuff, um but at least moving forward. You know it. It saves us there. I don't think it even needs to be a flag in the client could just be a thing that we a feature we implement and hey. It's only supported as of 7.12 or whatever.

B

So the only ask I would, I think, that's totally workable. The only ask I would have is that there's something that I can run in older npms to reliably determine if they support this or not without having to do version checking.

B

um If there's anything, I can just like I'm happy to put something in the pre-published script or whatever that just says like effectively. If npm doesn't support this feature crap out but like I need a way to do that and I feel.

H

Like that sounds like a good generic rfc of checking, support, yeah.

B

But it's about.

H

Like I need to.

E

B

That we can no longer change so.

E

Well, so here's the nice thing about that.

E

If we had a new, let's say we added a new top level command or just tacked it onto you know if you run npm versions right now, we just dump the version of npm and node and all the nodes things um if we made that look more like you know, when you run vim version right it, it prints out, like every switch, that it was configured with so that you can deterministically see like which, which features have been turned on or off uh a lot of tools do this like.

E

If we started plopping more stuff in that then okay, you run npm versions, json! You you pipe that to a thing that checks. If this flag is set and if not it fails, um that's pretty straightforward! Now it's going to accrete right, it's going to accumulate a lot of junk over time.

E

If we start saying well every new feature, we add we're going to make the output of this command a little bigger. I could see that getting out of hand, um but it's maybe it's fine. I don't know that that is a that is a new rfc, though you.

H

B

Yeah in instead of a list, it could even just be a single command where I say like npm like do you support and I give a string and then it just exits, zero or not, because then an npm that doesn't have that command will exit non-zero and that works out nicely. So.

E

That would be. That would be another kind of nice uh sugar. On top of that, so you don't have to dump the whole thing and parse it. You could just check for it right. You know, especially.

B

Since you're, mostly whatever yeah- and I don't want to have to do- json parsing in the shell.

H

I, like I, like darcy's suggestion.

A

I've been trying to get us to relocate doctor and which feels like you know these types of things like the sanity, checks etc. Like I feel like there's a case for us to look at doctor figure out if it like what feature set, it supports what why we have those checks in place and then also maybe expand it right, yeah yeah, it needs polish, but potentially npm doctor and then supports.

A

You know like a a sub command and then for that in the future that, like you literally, can rely on that to just fail, like for config um yeah thing to check yeah doctor thing to check even yeah, um so more arbitrary checks, yeah would be nice, um so yeah. It feels like there could be a lot of improvements made to npm doctor, which we could you know expand upon, and that would be the right scope for that kind of, like validation um but yeah. That feels a little bit different.

A

Oh rick, I know you have to drop. Was there anything specific you want to mention before you drop.

D

Oh no, no, I was just looking at the the rest of the things and uh I'll just keep my eyes open. Thanks, guys, cheers.

A

D

A

uh Just to be sensitive to time as well, uh because there's about 20 minutes left um if we have any other feedback, we want to give on like this rrfc, like this issue and thread and maybe give some context from this conversation back to that issue would be great. um It sounds like there's a couple ideas that could sprout an rfc. um I you know specifically jordan if you think that there's something you'd like that, we could have.

A

That would essentially help us in the future too, like something like that that validation, our supports you know, uh and if there's a way that we could like somehow backport that or have an identifier for you to use and yeah.

B

Yeah I mean, I think if folks are amenable, I can write an rfc for the something like npm doctor supports and then, if that can land first, then we could proceed with the npm ignore stuff. That would work great for me. Okay,.

A

uh Okay, uh moving on then um to rc 343, uh so this is roy's, unfortunately he's out this week, um but it's essentially the idea of auto switching the context um uh based on the cur switching. I think the current working directory um when we're running uh workspace commands.

A

um So the idea would be uh here- and I think I've explained this before that if I were to be running uh a workspace command inside of or if I'd be running a command inside of a workspace like npm install, it would actually de-sugar to um as if I were running that in the root of my workspace, so it would be npm install workspace whatever that workspace was, and so that was the idea behind this, and I think that we discussed the last time we talked about this.

A

You know, jordan, you brought up and it looks like you even added it here in terms of defining a workspace or or somehow making that connection explicit within the actual workspace back to the the parent. um I'm not sure if there's any any other conversations, unless you were the last one to like note uh or comment on this, I'm not sure you know, I'm not sure if we currently it's implemented um not this way. Currently we don't support this, so this would be like a net new um capability, but uh yeah, I'm not sure.

A

If anybody has any comments on this.

E

So my my only comment on this was it is extremely uh hazardous and- and it is extremely perilous to uh to say- oh I'm in a folder and you're running npm install.

E

Let me just walk up your directory tree and see if this folder is actually a workspace or if you know you don't even try to just infer it without making any changes locally.

E

Without making any explicit changes to just implicitly for uh what that were in a workspace, um we we kind of tossed it or tossed it about and talked about it. But it's it's really really hazardous. um You know there's already some cases like that, where we walk way further up the package up the folder tree than we really ought to um so one thing that we had, or one idea that occurred to me as we put some definitive marker in the workspace that says this is a workspace and its root is x.

E

um What that means is, though, that that gets away from you know wes's kind of uh suggested design constraint, which we've managed to meet so far, which is that if I, if I have a folder- and I have a bunch of just checked out projects- they don't need to know that they're workspaces, they don't need to have anything in them to define them as workspaces, and I can run workspace commands and have it. You know, build their package trees in a way that will work with them and pass their tests.

E

um In this case, we would have to put some kind of marker in that folder to say this is where you need to go look um for the root project, so that kind of gets us away from that. You know it's a violation of that constraint, somewhat um yep. That's it! That's it for me,.

A

So, are you basically saying you're in favor of uh jordan's suggestion, then making like an explicit file that points to the root? Is that kind of what you're saying.

E

uh Well, I'm I'm offering that, as I don't know, if I'm in favor of it, in any case, I I can see the value, but I'm more just saying like that is. That is the way that we could do this. uh This proposal right like with in a way that's not hazardous, but it does. I mean I'm calling out that it does violate that prior kind of design, constraint.

A

I would also because we brought this up like preemptively, I'm wondering like how time-sensitive this really is like so far like not that many people have complained, maybe because we're still slowly seeing adoption of our workspace implementation so and we're rolling out more and more command support. um So.

F

I guess would be that I I know for sure some of the things that uh are not yet supported are just blockers for for option, at least most of the main projects at netflix, though so you're not going to get yeah I've been able to get much feedback other than yeah it installs. um You know so we'll need those commands before we can know whether this is really a priority or not.

A

Right, it does seem like it's. This is for an improved developer experience right if you like, if your expectation also like, what's your expectation inside of a workspace like, do you want, for whatever reason just to install in place um like that folder or run that command explicitly in that directory and not like you might.

A

I would think that that's what I'm trying to do in that case like I would actually want that, and I wouldn't like the fact that that actually changed like that behavior changed unless there was some explicit config, as jordan and isaac have said right.

F

I think one thing that is a requirement not just um is the thing I mentioned here where you should be able to install a sibling package without having to go somewhere else, and I think that's a user experience requirement because I don't think people.

F

Because the other workflow would be edit, your package json delete your lock file and then rerun like.

C

I'm not actually sure.

F

What the workflow would be if you're, installing a sibling package without that feature- and I doubt most users are going to be all figured out and if that is the workflow, that's also pretty dangerous, because deleting a lock file, you know just to get a new package installed.

E

Seems what is when you say sibling package you mean, I have workspace a and I have workspace b and I want to say that a now depends on b yeah, exactly yeah.

E

Right, because what you want, is it to set up the proper links. So what? If what happens so yeah there's a question? There's an open. uh uh I have a draft pr uh which is the last on the agenda. We probably won't get to um to talk about kind of how we link or which things are shared and which things are not and so on, but would it work to do npm install b, dash dash yeah npm, install dot, slash b, dash dash workspace equals a that's. That's that's.

A

E

A

Yeah what I just typed in chat, I think, should do exactly what you're talking about wes here once um like in a little bit by the way so like in, like you know, uh hopefully the next like definitely by the end of this quarter, but uh even within the next month. We we have the ability to do this today. Our isaac did the work in our risk to actually have the support. We just need to wire up all the or npmi yeah.

F

Well, yeah: I was just specifically saying it doesn't work currently in the currently released version. um Yeah.

E

I would I thought that it did.

A

uh It won't know because it doesn't install, doesn't support workspaces or workspace. Yet.

E

Oh okay, well, there's some additional wiring.

F

Up work, um yeah wait a sec. Actually, though, there's one other detail here, I I was thinking you should be able to run this in the sub package, but I think this man has to be run from the.

E

Workspace route, correct yeah, so right now, everything's.

F

What we're talking about everything.

E

That's workspace aware today has to be run from the workspace project route right: okay, because we don't know that you're in a workspace.

F

You're, just in a folder yeah, and so if we add the dash workspace root configuration, we would then be able to run it from the child package, but you'd have to specify workspace root. You know dot, dot, slash or something.

E

Right or prefix dot slash would actually be the same thing.

A

So it sounds like uh just again I'd like to try to get to a couple of those last items here um for folks that are interested in in this, we'll probably keep it um open for now. It sounds like there's no immediate um change that we're we're going to move forward with.

A

um Also it would be great to have roy back uh to actually speak to this, um since I think he hasn't been able to join the last time a few times that we've actually talked to this, so um so we'll leave it open for now uh and feel free to add comments uh in the uh pr itself. um So moving on uh nilf uh had uh put together, rfc 336, the, where config parameter, for example, exec and npm config.

A

Essentially, we've talked about just the changing of the name. This seems rather uncontentious. I could be wrong. um Nope did you also, if you're on? Did you want to also just give a high level.

I

um So high level um right now, npm config, we have npm config set, and it is by default. Changing your user level config you can pass global. It will change your global config, there's no way to use npm config set to modify a project level config.

I

So if you needed to do something like say in this project, this scope maps to this registry, there is not a programmatic way to do that with the cly. So the way that I was thinking of fixing it is using dash dash where so you could specify exactly which config you want to make changes to.

I

um It would also apply to npm config git, because it would allow you, instead of seeing a list of all of your configs merged together, you could list the contents of just one of them, um then the other place where this uh seems like it would really have some advantages in npm exec. uh One of the things that we get a lot of questions about is when something's installed and you run it with npx. What does it actually run and right now it is kind of a strange cascade of things.

I

It checks your global bins, it checks your local bins.

I

Then it sees if it's a package name tries to install it sees if there's a bin it can run, and the order of precedence is not really clear and for some commands like typescript, where the name of the package is typescript, but the name of the bin is tsc, it becomes even more confusing because you can't just run it so the goal there was dash dash, where would allow you to say, specifically, run the bin, that's in my local project or run the global bin or run it by fetching this package name.

I

So, instead of having some kind of hand, wavy fallbacks a user can say this is the one I want run that and that is pretty much the whole thing. There was some bike shutting about what we would name the parameter.

I

uh Where seemed to make sense to me, it is used internally in some spots and in a couple of dependencies, but it didn't seem like it was super widespread. So I don't think that's a blocker.

A

Yeah, I think that was the only thing um yeah.

I

A

Anybody have any like negative feedback to this any. Like reason, we would push back on this other than the name yeah other than the name. This is great okay, so maybe we can just uh come up with a a poll or something for a few different names and see which uh which one folks prefer like location or be it very, very explicit, like.

B

Yeah and to be clear, I don't think there's any problem with the word where I think that's quite appropriate here. I think the problem is that due to the design of npm config and how a config flag applies to every command that it needs to be named in such a way that it's clear that it only applies to this one command, config, config location, might be.

E

Whatever yeah, it's actually two commands, though at least because we have um sure, but for exec as well.

B

So yeah just named in such a way so that there's no confusion as to what it will do on an unrelated command. I guess.

E

Yeah, it would be weird if I did npm install food dash dash where equals global, like that, installing it globally or what yeah.

A

um Car, I saw you got your hand up for a second, but maybe I well.

G

You kind of saw what I it it should really ex config level like it needs. The name needs to actually really describe what it's doing here. um Okay,.

I

So it could be that this ends up being two separate parameters. Then, because one is the location to a config and one is the source of exact location.

G

Location, yes, config, scope or config level like because we, the location, is because we we refer to them as, like user global package level, right, yeah, right.

E

But it's not taking a path so calling it location is kind of misleading.

I

Yeah, unless we made it so that it can take a path- and I don't know that we want.

E

To do that right and then what, if you give it a path which is not a config file we manage like? Should it just be right to an npmrc file and there's like.

A

E

Yeah yeah: this is.

D

F

E

We don't need to bike shut it here. This is the bike shed. We need to have, though, okay.

A

Great uh I'll put an action there for, for that um tuning. Did you want to quickly update on 182.

H

uh Quick update, I rewrote the rfc to be focused on uh using licensee. um There are some changes in there. uh It also based off. So I have. I have retained it as npm audit license. I I do think that's the better api uh or yeah. I think that's the better api, uh but I'm not hard attached to it, uh but based on some of jordan's feedback, I did also add uh some uh an additional commands, a flag section to make it. So uh no audit does both uh well, so it would all it.

H

This would also mean we add mpm audit security to just do security stuff uh and no audit security and audit license. Then audit, like no audit, does both those are all flags um and npm audit would do both.

B

I mean what would be nice is if there was a way that worked in old npms, that disabled security audits, but still allowed new npms to show licensing audits. That's my that's.

E

Well, it would it would right because no no security audit. Oh, I see what you mean so yeah, no audit in old npm, it's gonna yeah.

B

E

B

E

I have all over the place because I don't want to see false positives. I mean there's, there's a there's a way to construct that uh that setup, probably so that we can say explicitly. I do want to audit licenses.

H

Yeah um or just or just yeah, like yeah,.

E

uh But the can be, I.

C

Think doing it doing it.

E

uh Command space kind of makes sense, though I agree.

H

I yeah, and I I would specifically I I think this was also a note that uh both kat and rebecca uh shared with me- or maybe it was just cat. I don't know it was someone uh originally that was kind of the scope of audit, and I know that might have changed but like to be able to expand that and have it be more of a of a broad range rather than just cves.

E

Yeah, what happens if you do npm audit fix and the only problem is a lice? Is there any way to fix a license problem? Probably not.

H

Right right, yeah, that's not it's not something you can fix right. I mean that that would just eat the module uh like. If you want to do that, but yeah.

E

It sends an email to the module owner.

B

Asking them to hold on that's not entirely true, if you're, if you have version 1.2.3 of something and it's like licensed as gpl and version 124 exists and it's licensed as mit and you've said, you only want mit, then the fix is upgraded to one two. Four.

H

But wait could that actually be you that would have to be reversed right, because if it's gp.

B

Like I can't go yeah yeah, but I go from gp to mit.

H

B

It wouldn't be appropriate to do so in a patch, but it absolutely could.

D

H

Sorry, anyway, we don't need to get into licensing.

B

Yeah, whatever the direction I mean, what I mean is that there could be something could be suddenly dual licensed in the next version and the next version would satisfy, and so that's something a fix could do and it'd be probably nice to do that, because then it reduces the amount of manual license leg work. One has.

H

To do to make the lawyers happy yeah uh yeah I can. I can add that that I am happy to add that to the additional uh commands of flag sections um awesome.

A

Right yep, um so, unfortunately, we had two other items uh which we probably won't get to since we're essentially that time but feel free to comment on 156, the rrfc, optional, install and isaac's put on here a net new rc which is defining dependencies um and how they are shared. So jordan. I know you'll be interested in this and it's, uh I think, isaac. If you want to speak to this, I know you're not super.

E

A

The implementation so.

E

The um this is just discussing the uh uh user experience and um and sort of the the defaults in the semantics of like what we what we share and when between workspace projects, I actively hate the kind of straw proposal, package.json syntax for defining, which things get isolated, which ones don't so uh burn that all down give me a better way cause. I will be really sad if this is what we land on yeah. That's.

A

That's a good cap, yet, um okay, with uh with that said, uh we'll leave those on the agenda appreciate everybody joining today uh and uh hopefully we can keep working on the stuff together, async and we'll be back again next week, and hopefully you all have a great day thanks.

A