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