22:54 <ljharb> ELLIOTTCABLE: the problem with npm "files" is that if you forget to add a new file to the list, people get broken

22:54 <ljharb> i find that unacceptable, despite isaac's insistence that it can just be "fixed quickly"

22:54 <ljharb> if you forget to add a new file to npmignore, then the consequence is "everything works fine, but there's an extra file in the package that causes no harm to anyone"

22:59 <gkatsev> if only "fixed quickly" was a thing

23:00 <ELLIOTTCABLE> hmmmmm

23:00 <gkatsev> theoretically, it can be fixed quickly but so many times things don't get fixed immediately for whatever reason

23:00 <ELLIOTTCABLE> i'm not sure I agree wholly that that's "no harm to anyone", hrm

23:00 <ELLIOTTCABLE> that said, I ran into exactly that "files" issue recently lol

23:00 <ELLIOTTCABLE> didn't know until someone hunted me down on Discord and told me

23:01 <ELLIOTTCABLE> thx 4 repleh

23:01 <ELLIOTTCABLE> hey fun fact I dideded a thing

23:01 <ELLIOTTCABLE> within like an hour of installing Rust for the first time,

23:01 <ELLIOTTCABLE> I'd somehow tracked down a nasty segmentation-fault bug in the first library I tried to use, sourced a fix for the bug, and opened a pull-request with the fix to the author thereof

23:01 <ljharb> ELLIOTTCABLE: what's the harm you see?

23:01 <ELLIOTTCABLE> https://github.com/bcmyers/argonautica/pull/21

23:01 <ljharb> i mean, i recently accidentally leaked credentials this way

23:01 <ELLIOTTCABLE> it's cryptography stuff so I'm 4/10 hoping he doesn't merge it lololol because I don't wanna be responsible for that shit, buttttt, still proud

23:01 <ljharb> but that's harm *to me* which i'm in the position to fix

23:02 <ELLIOTTCABLE> okay so there's *at least* two issues here, which are getting very conflated and are extremely very unrelated

23:02 <ELLIOTTCABLE> the fact the two options take different stances on the two issues is simply coincidence, and should be ignored

23:02 <ELLIOTTCABLE> 1. numbers-of-sources-of-truth,

23:02 <ELLIOTTCABLE> 2. opt-in / opt-out (or explicit/implicit (or action/inaction)

23:03 <ljharb> there should only be one source of truth imo

23:03 <ELLIOTTCABLE> come at me lispers, one closing paren closes all prior opening parens, prove me wrong

23:03 <ELLIOTTCABLE> yeah, that's the point I feel strongly about

23:03 <ljharb> isaac's tweet was new info to me, that nested npmignores and files can coexist

23:03 <ELLIOTTCABLE> as for inclusion vs exclusion, hm, I remain undecided

23:03 <ljharb> i advocate for people to only use npmignore

23:03 <ELLIOTTCABLE> I think .npmignore is trash and should be avoided like the plague

23:03 <ljharb> an include list is best *iff* there's an easy way to test your package with excluded production files removed

23:03 <ljharb> oh i don't like npmignore as a thing

23:04 <ELLIOTTCABLE> but that's because I think the include/exclude failure-mode concern is _small potatoes_ compared to the sources-of-truth concern

23:04 <ljharb> but absent a good way to catch file exclusion in tests, an exclude list imo is the only safe option

23:04 <gkatsev> `npm pack` and then see what's in the tarball

23:04 <ljharb> ELLIOTTCABLE: well right but there's only one source of truth if you only pick one method

23:04 <ELLIOTTCABLE> er, no

23:04 <ljharb> ELLIOTTCABLE: isaac's original tweet was about expectations when there's more than one

23:04 <ELLIOTTCABLE> npmignore files explicitly allow/encourage multiple npmignore files.

23:04 <ljharb> gkatsev: that's not easy or ergonomic

23:04 <ELLIOTTCABLE> I'm not saying "files vs npmignore"

23:04 <ljharb> ELLIOTTCABLE: the feature does. but no docs or common usage does that.

23:04 <gkatsev> not necessarily, but it is an option

23:05 <ljharb> ELLIOTTCABLE: like i consider myself a bit of an npm expert, and i literally never knew you could have nested files

23:05 <ELLIOTTCABLE> I have only, _only_ ever seen it with multiple uses

23:05 <ljharb> i have 200 packages and they all have a single npmignore file.

23:05 <ELLIOTTCABLE> literally every project I've seen with an npmignore file, has more than one npmignore file.

23:05 <ljharb> and i've never once come across more than one

23:05 <ljharb> so clearly we run in different repos

23:05 <gkatsev> yeah, that was a first for me as well

23:05 <ELLIOTTCABLE> and it's *always* a pain to figure out when contributing, and it *always* causes bugs.

23:05 <ljharb> so yes, i agree

23:05 <ELLIOTTCABLE> hahahaha yeah no kidding

23:05 <ELLIOTTCABLE> BUT my point is this:

23:05 <ljharb> ELLIOTTCABLE: but that's a (good) argument to avoid more-than-one ignore file, which i'm on board with

23:05 <gkatsev> down with multiple npmignores

23:05 <ELLIOTTCABLE> I think maybe the best solution is to add a third way, with these properties:

23:06 <ELLIOTTCABLE> 1. using it is runtime-error incompatible with either of the previous ones

23:06 <ljharb> interested to hear this because that's what isaac asked me to sketch out

23:06 <gkatsev> it makes sense that's it's allowed because gitignore, but even that I generally only ever have one at the root

23:06 <ELLIOTTCABLE> 2. using it requires full enumeration in a single place

23:06 <ELLIOTTCABLE> and 3. if you prefer (and I don't necessarily disagree with your arguments!), it can default to including unlisted files

23:06 <ljharb> disagree with number 1, because older npm versions need a fallback

23:06 <ELLIOTTCABLE> but the important things to me are 1 and 2.

23:06 <ljharb> 2 i'm fully on board with

23:06 <ELLIOTTCABLE> but this is for -building-

23:06 <ELLIOTTCABLE> why need backwards compatibility?

23:06 <ljharb> multiple people publish packages using multiple npm versions

23:06 <ljharb> it's super rare to force an npm version on developers of your project

23:07 <ljharb> and it almost never matters.

23:07 <ELLIOTTCABLE> yiiiiiiiiiiiiiiikes

23:07 <ljharb> if i use the new thing and delete files/npmignore, the danger is *much* larger

23:07 <ljharb> because then it falls back to gitignore, which will ignore build output in any package with transpilation

23:07 <ljharb> super not worth the risk

23:07 <ELLIOTTCABLE> yeah and now we're back to multiple sources of truth

23:07 <ELLIOTTCABLE> fucking gross

23:07 <ljharb> it'd only be one source per npm version

23:07 <ljharb> but yeah i agree it's gross

23:07 <ljharb> but back compat rules all

23:08 <ljharb> if npm adds some magic third way, and it's better, than perhaps in a few years we can drop the old ways

23:08 <ELLIOTTCABLE> n>1 is the same problem as 10,000, when it comes to this, though; the "count" doesn't really matter if it's not 1

23:08 <ljharb> we play the long game.

23:08 <ljharb> sure, i agree with that

23:08 <ljharb> but as i said, i've never seen > 1

23:08 <ljharb> so i'd just fix that when you find it :-p

23:08 <ELLIOTTCABLE> well wait, though, your argument seems to not just break *my* idea, but *any* possible solution

23:08 <ljharb> i've never seen more than one gitignore either tbh

23:08 <ELLIOTTCABLE> so is your argument literally "this can't be changed or fixed, don't touch it or make it better?"

23:09 <ljharb> no

23:09 <ljharb> my argument is, you can never have one source of truth across npm versions

23:09 <ljharb> so, drop that requirement, as long as *in a new npm version* there can only be one

23:09 <ELLIOTTCABLE> so the pattern I've seen over, and over, and over, both with git 'n npm ignorefiles, is one developer expects/wants/creates them in src/ and test/ separately; and then another developer, not realising that, creates one (usually by copy-pasting a standard one and then adding The One Thing They Care About) at the project-root

23:10 <ELLIOTTCABLE> so the problematic N I'm used to seeing is very specifically 3 (or more rarely, 4, if there's a docs/ or examples/ or whatever)

23:10 <ljharb> so you gitignore all nested ignore files at the root

23:10 <ELLIOTTCABLE> I've almost never seen other ones *deeper*

23:10 <ljharb> then they'd have to use `-f` to override it

23:10 <ljharb> ie, `**/.gitignore` in .gitignore

23:10 <ljharb> ertc

23:10 <ELLIOTTCABLE> just that one dichotomy between contributors who only pay attention to subdirectories, and contributors who only pay attention to the root

23:10 <ljharb> both are wrong

23:11 <ljharb> but all the config and commands run should always be only in the root

23:11 <ljharb> so the former are more wrong

23:11 <ELLIOTTCABLE> ugh unrelatedly to the original topic but —

23:11 <ljharb> (altho i also hate monorepos, where it gets fuzzier)

23:11 <ELLIOTTCABLE> as a root'er, doing OCaml stuff has been driving me _nuts_

23:11 <ELLIOTTCABLE> because Dune / OCaml community firmly believes config and stuff should live directly adjacent to the file it's affecting

23:11 <ELLIOTTCABLE> so every project has a `dune` file and `.merlin` in every g/d source-directory in the project

23:12 <ljharb> gross

23:14 <ELLIOTTCABLE> okay, how's this for incremental steps.

23:14 <ELLIOTTCABLE> I really, _really_ hate littering directories with yet-more files, esppppeeeccccially when Node crap has already forced five or six goddamn files on me per-directory (and that's before this conversation / suggestion, so, seven(!) if this happened?),

23:15 <ELLIOTTCABLE> but noting backwards-compat and the danger of default-exclude, maybe the best way forward is to deprecate the `"files"` array *and* any more than a single `.npmignore` per project?

23:15 <ljharb> i'd like that, but isaac/npm believes "files" is the better choice

23:15 <ljharb> we really need something different and better

23:16 <ELLIOTTCABLE> but you yourself argued that's impossible to add, because apparently we're gonna support people being idiotic and not specifying the supported tooling version

23:16 <ELLIOTTCABLE> ("we're" being the hypothetical us that are in charge of things for dialectical purposes 🤣)

23:16 <ELLIOTTCABLE> that's one thing Dune nailed — it's had versioned config for, well, since the very start

23:17 <ljharb> it's not impossible to add

23:17 <ELLIOTTCABLE> I think, despite being young, it's six or seven config-versions in? and has extremely powerful interactive / automatic conversion / upgrading.

23:17 <ljharb> it just means that there could be multiple sources of truth, for awhile. and that's ok.

23:17 <ljharb> because it puts us on a path to ONE source of truth, eventually.

23:19 <ELLIOTTCABLE> ehhhhhhhhhhhhhhhhhhh, what do you mean by "different and better"

23:20 <ELLIOTTCABLE> ahhhhhh talking about this is prolly a waste of time, but it was fun <3