privacytools / privacytools.io

🛡🛠 You are being watched. Protect your privacy against global mass surveillance.
https://www.privacyguides.org
Creative Commons Zero v1.0 Universal
3.12k stars 384 forks source link

✨ Feature Suggestion | Use npm/yarn #1334

Open dawidpotocki opened 5 years ago

dawidpotocki commented 5 years ago

At the moment we just have Font Awesome, Bootstrap, jQuery and other JavaScript files just being uploaded to repository. It makes updating and managing it a bit harder and also makes repository a bit bloated, as binary and minified files diff bad.

My suggestion is to use yarn or npm for managing JavaScript/CSS/Font dependencies. I like myself yarn more than npm, so that's what I recommend. Yes, that will introduce more tooling, but with a good CONTRIBUTING.md it should be easy for new contributors.

I am fine with doing all the work required.

nitrohorse commented 5 years ago

Hmm okay, so to clarify we'd rely on npm or yarn for managing our external JS dependencies, something like?

{
  // ...
  "devDependencies": {
    "bootstrap": "^4.1.3",
    "jquery": "^3.3.1",
    // ...
  }
}

Also worth calling out is the past security issues with npm packages and how packages become insanely deep. In regards to the depth "issue," I usually like pnpm:

pnpm uses hard links and symlinks to save one version of a module only ever once on a disk. When using npm or Yarn for example, if you have 100 projects using the same version of lodash, you will have 100 copies of lodash on disk.

In regards to security, we'd probably want to later look into npm audit, yarn audit, Snyk, or Greenkeeper for ideas how to make sure we can deal with security issues quickly that come up for any dependency. I'm likely overthinking right now but it's best to mention this I think.

And regardless, using a package manager makes sense for maintainability in the long-run plus being able to update package versions easier. And an easy-to-follow CONTRIBUTING.md would be great so that new developers won't get tripped up with this when they want to contribute to the repo.

dawidpotocki commented 5 years ago

Hmm okay, so to clarify we'd rely on npm or yarn for managing our external JS dependencies, something like?

{
  // ...
  "devDependencies": {
    "bootstrap": "^4.1.3",
    "jquery": "^3.3.1",
    // ...
  }
}

Yes.

In regards to the depth "issue," I usually like pnpm:

pnpm uses hard links and symlinks to save one version of a module only ever once on a disk. When using npm or Yarn for example, if you have 100 projects using the same version of lodash, you will have 100 copies of lodash on disk.

Maybe I'm wrong, but isn't Yarn's Plug'n'Play the solution? https://yarnpkg.com/lang/en/docs/pnp/

nitrohorse commented 5 years ago

Whoa, TIL thx for sharing 👍🏼 Looks like that can work.

nitrohorse commented 5 years ago

A comment I made in our Wire team chat:

I was talking with a co-worker today about Yarn vs NPM and he mentioned in his perspective Yarn gained popularity when it came out because it did a lot of things NPM didn't do but now where things are at the biggest diff in his mind is this aspect of Yarn called "workspaces" which I'm not really familiar with [1]. He said "Yarn = NPM + Lerna [2]" which apparently is helpful for a mono-repo setup.

However, I forgot to mention "PnP" [3] from Yarn which removes the need for node_modules like @dawidpotocki brought up. I can't find anything from Node for that configurability except using something different like pnpm [4].

Overall, I'd go with Yarn because of the node_modules aspect. But I don't think we can go wrong either way.

[1] https://yarnpkg.com/lang/en/docs/workspaces/ [2] https://github.com/lerna/lerna [3] https://yarnpkg.com/lang/en/docs/pnp/ [4] https://pnpm.js.org/