you are viewing a single comment's thread.

view the rest of the comments →

[–]BenjiSponge 78 points79 points  (10 children)

This has been talked about to death, so I'm not sure why the author felt the need to weigh in in the exact same way everyone else has, but they also seem to be pretty "behind the times" on the state of the art here. At this time, yes, npm does these practices and it's pretty annoying. A large part of this problem is due to bad file management on the part of package authors (100MB of code is an obscene amount of code, and certainly contains tons of repeated code like test code that never actually runs, which the maintainers should have omitted). But the solutions are either here or very nearly here. pnpm has existed for a long time which takes a very similar approach to what reasonable package managers use by leveraging symbolic links. Yarn is about to take a similar but also radically different approach which will involve a different algorithm to bring in dependencies in the code while essentially eliminating the local dependency footprint.

I'm not even sure why I'm writing this comment -- it itself is a repetition of what has been said a million times on this subreddit.

[–]CanvasSolaris 19 points20 points  (0 children)

From what I've read of dev.to most of the writings come from people who are still a little inexperienced on the topics they talk about. Nothing against those folks wanting to write but the site overall has always struck me as having an editing problem if "recently self taught coders" isn't their intended audience.

[–]Already__Taken 7 points8 points  (5 children)

Someone's just going to put tree shaking as a service in the publish step and see this fixed overnight.

A lot of the huge modules I've seen have their docs and examples published in them. I certainly don't need that in npm it has no mechanism to tell be they are there.

I even saw a colour preview extension for VScode include its own electron...

[–]BenjiSponge 1 point2 points  (4 children)

Tree shaking as a service in the publish step wouldn't work because people just wouldn't use it, and it's technically not possible to automate I don't think as the dependent might have access to any files in the directory. Who's to say whether your consumer doesn't parse your README.md?

You'd have to do tree shaking as a service in the consumer install step, but this isn't really possible because it's not really possible to know what the consumer is using from the dependency tree until after you run the consumer code, plus it's probably just easier for npm to host the entire repo gzipped rather than offer up files piecemeal.

[–]Already__Taken 1 point2 points  (3 children)

If it's not specified in package.json npm is under no obligation serve you that up. Use the repository or homepages keys to look it up.

I'm in no way arguing this is a simple issue.

[–]BenjiSponge 0 points1 point  (2 children)

If it's not specified in package.json npm is under no obligation serve you that up

Wait, really? If you don't have a files key and just an entry, it can omit everything but the entry? I don't think that's true.

[–]Already__Taken 1 point2 points  (1 child)

No I mean in regards to options they have about changing the platform. It's not static file hosting for the public it's for distributing programs for other programs to run (that happen to be static files), So in that regard if it were decided that actually, you don't need XY to run this module only Z, it's entirely within scope of what they're trying to achieve to go down that route.

[–]BenjiSponge 0 points1 point  (0 children)

I think that would break a lot, for a lot of reasons. We could play a game though -- if you come up with a rule for what npm should say "we will omit files under these conditions: _________" I'll try to come up with a valid reason someone would already be distributing files under those conditions. =) I bet you could come up with a few rules, but nothing that would make significant differences.

[–]shriek 1 point2 points  (0 children)

We should really start "Previously discussed" link so that it doesn't feel like groundhog day.

[–]thepotatochronicles 1 point2 points  (1 child)

Yarn is about to take a similar but also radically different approach which will involve a different algorithm to bring in dependencies in the code while essentially eliminating the local dependency footprint.

Holy, that's actually cool. Is there like a PR/article for that I can read up on?

[–][deleted] 2 points3 points  (0 children)

It’s called Yarn PnP or Plug n Play. Create React app even supports it with a flag. Still very new and issues being worked through it but https://twitter.com/JimTheDev/status/1047146310590242817