ec changed the topic of #elliottcable to: a π•―π–Šπ–“ 𝖔𝖋 π•―π–Šπ–™π–Šπ–—π–’π–Žπ–“π–Šπ–‰ π•―π–†π–’π–˜π–Šπ–‘π–˜ slash sΝ”ΜžuΝ•Ν™pΝ™Ν“e̜̺rΜΌΜ¦i̼̜oΜ–Μ¬rΜ™Μ™ c̝͉α»₯Μ§Ν˜αΈ·Μ‘Ν™Ε£Ν“Μ€ || #ELLIOTTCABLE is not about ELLIOTTCABLE
Rurik has quit [Quit: Rurik]
Sgeo_ has joined #elliottcable
Sgeo has quit [Ping timeout: 246 seconds]
Sgeo_ has quit [Read error: Connection reset by peer]
Sgeo_ has joined #elliottcable
Sgeo_ has quit [Read error: Connection reset by peer]
Sgeo_ has joined #elliottcable
_whitelogger has joined #elliottcable
Rurik has joined #elliottcable
Rurik has quit [Quit: Rurik]
Rurik has joined #elliottcable
<ljharb> ELLIOTTCABLE: the problem with npm "files" is that if you forget to add a new file to the list, people get broken
<ljharb> i find that unacceptable, despite isaac's insistence that it can just be "fixed quickly"
<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"
<gkatsev> if only "fixed quickly" was a thing
<ELLIOTTCABLE> hmmmmm
<gkatsev> theoretically, it can be fixed quickly but so many times things don't get fixed immediately for whatever reason
<ELLIOTTCABLE> i'm not sure I agree wholly that that's "no harm to anyone", hrm
<ELLIOTTCABLE> that said, I ran into exactly that "files" issue recently lol
<ELLIOTTCABLE> didn't know until someone hunted me down on Discord and told me
<ELLIOTTCABLE> thx 4 repleh
<ELLIOTTCABLE> hey fun fact I dideded a thing
<ELLIOTTCABLE> within like an hour of installing Rust for the first time,
<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
<ljharb> ELLIOTTCABLE: what's the harm you see?
<ljharb> i mean, i recently accidentally leaked credentials this way
<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
<ljharb> but that's harm *to me* which i'm in the position to fix
<ELLIOTTCABLE> okay so there's *at least* two issues here, which are getting very conflated and are extremely very unrelated
<ELLIOTTCABLE> the fact the two options take different stances on the two issues is simply coincidence, and should be ignored
<ELLIOTTCABLE> 1. numbers-of-sources-of-truth,
<ELLIOTTCABLE> 2. opt-in / opt-out (or explicit/implicit (or action/inaction)
<ljharb> there should only be one source of truth imo
<ELLIOTTCABLE> come at me lispers, one closing paren closes all prior opening parens, prove me wrong
<ELLIOTTCABLE> yeah, that's the point I feel strongly about
<ljharb> isaac's tweet was new info to me, that nested npmignores and files can coexist
<ELLIOTTCABLE> as for inclusion vs exclusion, hm, I remain undecided
<ljharb> i advocate for people to only use npmignore
<ELLIOTTCABLE> I think .npmignore is trash and should be avoided like the plague
<ljharb> an include list is best *iff* there's an easy way to test your package with excluded production files removed
<ljharb> oh i don't like npmignore as a thing
<ELLIOTTCABLE> but that's because I think the include/exclude failure-mode concern is _small potatoes_ compared to the sources-of-truth concern
<ljharb> but absent a good way to catch file exclusion in tests, an exclude list imo is the only safe option
<gkatsev> `npm pack` and then see what's in the tarball
<ljharb> ELLIOTTCABLE: well right but there's only one source of truth if you only pick one method
<ELLIOTTCABLE> er, no
<ljharb> ELLIOTTCABLE: isaac's original tweet was about expectations when there's more than one
<ELLIOTTCABLE> npmignore files explicitly allow/encourage multiple npmignore files.
<ljharb> gkatsev: that's not easy or ergonomic
<ELLIOTTCABLE> I'm not saying "files vs npmignore"
<ljharb> ELLIOTTCABLE: the feature does. but no docs or common usage does that.
<gkatsev> not necessarily, but it is an option
<ljharb> ELLIOTTCABLE: like i consider myself a bit of an npm expert, and i literally never knew you could have nested files
<ELLIOTTCABLE> I have only, _only_ ever seen it with multiple uses
<ljharb> i have 200 packages and they all have a single npmignore file.
<ELLIOTTCABLE> literally every project I've seen with an npmignore file, has more than one npmignore file.
<ljharb> and i've never once come across more than one
<ljharb> so clearly we run in different repos
<gkatsev> yeah, that was a first for me as well
<ELLIOTTCABLE> and it's *always* a pain to figure out when contributing, and it *always* causes bugs.
<ljharb> so yes, i agree
<ELLIOTTCABLE> hahahaha yeah no kidding
<ELLIOTTCABLE> BUT my point is this:
<ljharb> ELLIOTTCABLE: but that's a (good) argument to avoid more-than-one ignore file, which i'm on board with
<gkatsev> down with multiple npmignores
<ELLIOTTCABLE> I think maybe the best solution is to add a third way, with these properties:
<ELLIOTTCABLE> 1. using it is runtime-error incompatible with either of the previous ones
<ljharb> interested to hear this because that's what isaac asked me to sketch out
<gkatsev> it makes sense that's it's allowed because gitignore, but even that I generally only ever have one at the root
<ELLIOTTCABLE> 2. using it requires full enumeration in a single place
<ELLIOTTCABLE> and 3. if you prefer (and I don't necessarily disagree with your arguments!), it can default to including unlisted files
<ljharb> disagree with number 1, because older npm versions need a fallback
<ELLIOTTCABLE> but the important things to me are 1 and 2.
<ljharb> 2 i'm fully on board with
<ELLIOTTCABLE> but this is for -building-
<ELLIOTTCABLE> why need backwards compatibility?
<ljharb> multiple people publish packages using multiple npm versions
<ljharb> it's super rare to force an npm version on developers of your project
<ljharb> and it almost never matters.
<ELLIOTTCABLE> yiiiiiiiiiiiiiiikes
<ljharb> if i use the new thing and delete files/npmignore, the danger is *much* larger
<ljharb> because then it falls back to gitignore, which will ignore build output in any package with transpilation
<ljharb> super not worth the risk
<ELLIOTTCABLE> yeah and now we're back to multiple sources of truth
<ELLIOTTCABLE> fucking gross
<ljharb> it'd only be one source per npm version
<ljharb> but yeah i agree it's gross
<ljharb> but back compat rules all
<ljharb> if npm adds some magic third way, and it's better, than perhaps in a few years we can drop the old ways
<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
<ljharb> we play the long game.
<ljharb> sure, i agree with that
<ljharb> but as i said, i've never seen > 1
<ljharb> so i'd just fix that when you find it :-p
<ELLIOTTCABLE> well wait, though, your argument seems to not just break *my* idea, but *any* possible solution
<ljharb> i've never seen more than one gitignore either tbh
<ELLIOTTCABLE> so is your argument literally "this can't be changed or fixed, don't touch it or make it better?"
<ljharb> no
<ljharb> my argument is, you can never have one source of truth across npm versions
Rurik has quit [Ping timeout: 268 seconds]
<ljharb> so, drop that requirement, as long as *in a new npm version* there can only be one
<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
<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)
<ljharb> so you gitignore all nested ignore files at the root
<ELLIOTTCABLE> I've almost never seen other ones *deeper*
<ljharb> then they'd have to use `-f` to override it
<ljharb> ie, `**/.gitignore` in .gitignore
<ljharb> ertc
<ELLIOTTCABLE> just that one dichotomy between contributors who only pay attention to subdirectories, and contributors who only pay attention to the root
<ljharb> both are wrong
<ljharb> but all the config and commands run should always be only in the root
<ljharb> so the former are more wrong
<ELLIOTTCABLE> ugh unrelatedly to the original topic but β€”
<ljharb> (altho i also hate monorepos, where it gets fuzzier)
<ELLIOTTCABLE> as a root'er, doing OCaml stuff has been driving me _nuts_
<ELLIOTTCABLE> because Dune / OCaml community firmly believes config and stuff should live directly adjacent to the file it's affecting
<ELLIOTTCABLE> so every project has a `dune` file and `.merlin` in every g/d source-directory in the project
<ljharb> gross
<ELLIOTTCABLE> okay, how's this for incremental steps.
<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?),
<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?
<ljharb> i'd like that, but isaac/npm believes "files" is the better choice
<ljharb> we really need something different and better
<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
<ELLIOTTCABLE> ("we're" being the hypothetical us that are in charge of things for dialectical purposes 🀣)
<ELLIOTTCABLE> that's one thing Dune nailed β€” it's had versioned config for, well, since the very start
<ljharb> it's not impossible to add
<ELLIOTTCABLE> I think, despite being young, it's six or seven config-versions in? and has extremely powerful interactive / automatic conversion / upgrading.
<ljharb> it just means that there could be multiple sources of truth, for awhile. and that's ok.
<ljharb> because it puts us on a path to ONE source of truth, eventually.
<ELLIOTTCABLE> ehhhhhhhhhhhhhhhhhhh, what do you mean by "different and better"
<ELLIOTTCABLE> ahhhhhh talking about this is prolly a waste of time, but it was fun <3