✨ Feature Suggestion | Use npm/yarn #1334

New Issue

2019-09-22T00:05:16Z

dawidpotocki commented

2019-09-22 00:05:16 +00:00

(Migrated from github.com)

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.

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.

👍 1

nitrohorse commented

2019-09-22 02:54:53 +00:00

(Migrated from github.com)

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.

Hmm okay, so to clarify we'd rely on npm or yarn for managing our external JS dependencies, something like? ```javascript { // ... "devDependencies": { "bootstrap": "^4.1.3", "jquery": "^3.3.1", // ... } } ``` Also worth calling out is the past [security issues with npm packages](https://www.techrepublic.com/article/heres-how-npm-plans-to-improve-security-and-reliability-in-2019/) and how packages become insanely deep. In regards to the depth "issue," I usually like [pnpm](https://pnpm.js.org/en/motivation): > 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](https://docs.npmjs.com/cli/audit), [yarn audit](https://yarnpkg.com/lang/en/docs/cli/audit/), [Snyk](https://snyk.io/), or [Greenkeeper](https://greenkeeper.io/) 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

2019-09-22 04:24:12 +00:00

(Migrated from github.com)

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/

> Hmm okay, so to clarify we'd rely on npm or yarn for managing our > external JS dependencies, something like? > ```javascript > { > // ... > "devDependencies": { > "bootstrap": "^4.1.3", > "jquery": "^3.3.1", > // ... > } > } > ``` Yes. > In regards to the depth "issue," I usually like > [pnpm](https://pnpm.js.org/en/motivation): > > 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

2019-09-22 04:36:10 +00:00

(Migrated from github.com)

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

nitrohorse commented

2019-09-28 01:59:48 +00:00

(Migrated from github.com)

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/

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/

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: privacyguides/privacytools.io#1334