Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

This should be a StackOverflow article, not a library #41

Closed
michaelkleinhenz opened this issue Apr 28, 2020 · 2 comments
Closed

This should be a StackOverflow article, not a library #41

michaelkleinhenz opened this issue Apr 28, 2020 · 2 comments

Comments

@michaelkleinhenz
Copy link

This module is just ridiculous. The existence of "libraries" like this compromises the consistency and long-term viability of the JS ecosystem. This should not exist.

@Qix-
Copy link

Qix- commented Apr 28, 2020

Here are some facts to consider before bringing your pitchforks and torches:

  • Developers choose to use trivial modules; it's a two way street. If e.g. create-react-app chose to use this module and use a range-based semver specifier, that's something you should bring up with them as a concern.
  • You cannot prevent low-quality or low-effort or toy modules from being published.
  • There are thousands of similarly trivial modules on npm right now.
  • By using a dependency, you are at the mercy of that dependency and all of its dependencies, too. Along with those dependencies' dependencies, and so on. You are just as responsible for the inflation of your own codebase vis-a-vis dependencies; less LOC in your own, project-specific code does NOT equate to less LOC overall.
  • You cannot unpublish a module on npm after 24 hours. Telling the maintainer to remove this and that it "should not exist" is a fruitless endeavor.

Here are some ways to protect yourself. These are subjective and open to debate, but they're rules I follow in all of my own projects after almost 10 years writing and maintaining Node.js/npm packages:

  • Pin your dependencies. Add save-exact=true on its own line in a file called .npmrc in the root of your repository. This tells npm/yarn to omit the range prefix on packages installed with npm install/yarn install, pinning the package. Further, remove any range prefixes from your dependencies/devDependencies/etc. that might already exist in your package.json.
  • Don't use lockfiles. This is a highly controversial point, but the security tradeoffs are very debatable and by pinning dependencies you help mitigate this. There's a larger discussion to be had here, but in my own experience they have only caused issues both in development and production (including deployment pipelines), many of which are delayed/subtle.
  • Use a mirror. Setting up a CouchDB mirror is trivial and will mitigate any outages, etc. you might face.

Accidents happen. It happens quite1 often2. It's a part of software development. It's a part of any engineering field.

Complaining helps nothing.

@then then locked and limited conversation to collaborators Apr 28, 2020
@ForbesLindesay
Copy link
Member

These issues do not help anyone. There are plenty of good reasons to have and use small packages like this, but I have no interest in explaining them again as clearly none of the people on this issue have bothered to look through the other issues. I've blocked anyone who up-voted this issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants