fix(api): lint all dependencies in package-lock #53

JamesSingleton · 2020-01-28T22:41:33Z

Will not override in the object if there is a matching dep and version
and will lint all the dependencies of dependencies.

Fixes #49

Description

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)

Related Issue

#49

Motivation and Context

It solved the issue where if multiple dependencies had the same subdependencies (name and version) only one was added to the object. This was an issue if the first one was corrupt but the last one was fine, it would not be caught.

How Has This Been Tested?

Manually tested locally
All unit tests are passing

Screenshots (if appropriate):

Checklist:

I have updated the documentation (if required).
I have read the CONTRIBUTING document.
I have added tests to cover my changes.
All new and existing tests passed.
I added a picture of a cute animal cause it's fun

JamesSingleton · 2020-01-28T22:42:48Z

One thing I want to mention is this now will not longer catch something like

 "lockfile-lint": {
      "version": "file:../lockfile-lint/packages/lockfile-lint/lockfile-lint-3.0.8.tgz",
      "integrity": "sha512-rS+Xbf31aGpj/vXAokFNjCobPEWT0IkeGpWY6ZwPdtlW80WAF13gZfkAIvxWvbl4yORhFvCXDOmSWzHCnBT78Q==",
      "dev": true,
      "requires": {
        "debug": "^4.1.1",
        "lockfile-lint-api": "file:../lockfile-lint/packages/lockfile-lint-api/lockfile-lint-api-5.0.7.tgz",
        "yargs": "^15.0.2"
      },

However, this I believe is a different issue all together and am willing to open an issue in regards to this.

codecov-io · 2020-01-28T22:47:37Z

Codecov Report

Merging #53 into master will decrease coverage by 2.8%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #53      +/-   ##
==========================================
- Coverage   97.88%   95.08%   -2.81%     
==========================================
  Files          11       11              
  Lines         189      183       -6     
  Branches       29       29              
==========================================
- Hits          185      174      -11     
- Misses          4        8       +4     
- Partials        0        1       +1

Impacted Files	Coverage Δ
.../lockfile-lint-api/src/validators/ValidateHttps.js	`100% <ø> (ø)`	⬆️
...s/lockfile-lint-api/src/validators/ValidateHost.js	`100% <ø> (ø)`	⬆️
...lockfile-lint-api/src/validators/ValidateScheme.js	`100% <100%> (ø)`	⬆️
packages/lockfile-lint-api/src/ParseLockfile.js	`100% <100%> (ø)`	⬆️
...kages/lockfile-lint-api/src/common/PackageError.js	`0% <0%> (-100%)`	⬇️
packages/lockfile-lint/src/cli.js	`0% <0%> (ø)`	⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c7671ac...989d9a2. Read the comment docs.

Will not override in the object if there is a matching dep and version and will lint all the dependencies of dependencies. Fixes #49

lirantal · 2020-02-01T09:08:50Z

@JamesSingleton can you elaborate your last comment about why it would not catch that kind of structure and what exactly will be missed?

lirantal · 2020-02-01T09:15:24Z

packages/lockfile-lint-api/src/ParseLockfile.js

    for (const [depName, depMetadata] of Object.entries(npmDepsTree)) {
      const depMetadataShortend = {
        version: depMetadata.version,
-        resolved: depMetadata.resolved ? depMetadata.resolved : depMetadata.version,
+        resolved: depMetadata.resolved,


@JamesSingleton can you comment why was this changed?
IIRC this was supposed to solve cases where a resolved property may not be there but a version would, for cases like local file URLs or something like this.

So this is due to the new URL(metadata.resolved) failing if this is a version?
I'll track back the source of this and we'll find out.

From #49 (comment)

The error points to this line

try { packageResolvedURL = new URL(packageMetadata.resolved) } catch (error) { throw new PackageError(packageName, error) }

Not sure how this is now just coming up now though. Looks like this will happen with any dependency that does not have a true URL for resolved since resolved is optional and doing new URL("1.1.1") is not a valid URL.

Sounds like you're saying this is a general bug unrelated to this change.
I tracked the source of using the version to a package-lock.json structure where the version field is used to specify the git URL, see here: a483115#diff-24ebf59c7b0eeb6040c5311942ef4a3eR16

@JamesSingleton nevermind here since we already have this discussion going on #54

lirantal · 2020-02-01T09:16:52Z

@JamesSingleton I see you've taken the approach of keeping the object structure but with a modification for it being a hash. Did you find this solution better than just changing it to an array structure?

lirantal · 2020-02-01T09:37:54Z

You've also referred to an issue with one of the tests in the last comment in the issue, here: #49 (comment)

Is this PR solving that or is that still something we need to fix?

JamesSingleton · 2020-02-01T17:38:42Z

@JamesSingleton I see you've taken the approach of keeping the object structure but with a modification for it being a hash. Did you find this solution better than just changing it to an array structure?

@lirantal, I felt that it was a better solution in my opinion.

lirantal · 2020-02-01T19:19:09Z

@JamesSingleton in any specific way?
I mean, an object is nice because it's a dictionary structure that you can easily get the package if you know it's name/version but with the hash that's not possible anymore. I guess I could argue that it is much of a breaking change as just using arrays.

JamesSingleton · 2020-02-01T19:22:23Z

I keep the name and version along with the hash. The hash was just to make it unique and not have to redo all the validators.

lirantal · 2020-02-01T19:25:06Z

@JamesSingleton alright. I'm not entirely against doing as you proposed either but can assume that in the long run we will probably move to an array structure.

I'm ok to move forward with this

JamesSingleton · 2020-02-03T16:14:59Z

@lirantal can we move forward with merging this?

Francois-Esquire · 2020-02-03T18:41:54Z

Thank you @lirantal for taking time to work through and merge the PR! Question for you, when can we expect a release?

lirantal · 2020-02-03T22:12:17Z

New versions released 🎉

lockfile-lint@3.0.10
lockfile-lint-api@5.0.8

lirantal · 2020-02-03T22:12:39Z

thanks @JamesSingleton for your contribution on this 💜

a regression introduced via PR #53 due to flat package list now being all-inclusive of packages, some of which have no protocol or URL to resolve to (the nested deps) and so the validators failed.

JamesSingleton mentioned this pull request Jan 28, 2020

Check version is actually a proper semver version #54

Closed

fix(api): lint all dependencies in package-lock

dfced24

Will not override in the object if there is a matching dep and version and will lint all the dependencies of dependencies. Fixes #49

lirantal self-requested a review February 1, 2020 09:05

lirantal assigned JamesSingleton Feb 1, 2020

lirantal reviewed Feb 1, 2020

View reviewed changes

lirantal added the bug Something isn't working label Feb 1, 2020

chore(try-catch): revert try catch changes

989d9a2

lirantal merged commit f5bb8ca into lirantal:master Feb 3, 2020

lirantal mentioned this pull request Feb 4, 2020

fix(validators): only validating when URL is present #59

Merged

3 tasks

lirantal mentioned this pull request Feb 4, 2020

Add missing unit test coverage for PR #59 #60

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(api): lint all dependencies in package-lock #53

fix(api): lint all dependencies in package-lock #53

JamesSingleton commented Jan 28, 2020

JamesSingleton commented Jan 28, 2020

codecov-io commented Jan 28, 2020 •

edited

lirantal commented Feb 1, 2020

lirantal Feb 1, 2020

lirantal Feb 1, 2020

lirantal Feb 1, 2020

lirantal Feb 1, 2020

lirantal commented Feb 1, 2020

lirantal commented Feb 1, 2020

JamesSingleton commented Feb 1, 2020

lirantal commented Feb 1, 2020

JamesSingleton commented Feb 1, 2020

lirantal commented Feb 1, 2020

JamesSingleton commented Feb 3, 2020

Francois-Esquire commented Feb 3, 2020

lirantal commented Feb 3, 2020

lirantal commented Feb 3, 2020

fix(api): lint all dependencies in package-lock #53

fix(api): lint all dependencies in package-lock #53

Conversation

JamesSingleton commented Jan 28, 2020

Description

Types of changes

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Checklist:

JamesSingleton commented Jan 28, 2020

codecov-io commented Jan 28, 2020 • edited

Codecov Report

lirantal commented Feb 1, 2020

lirantal Feb 1, 2020

Choose a reason for hiding this comment

lirantal Feb 1, 2020

Choose a reason for hiding this comment

lirantal Feb 1, 2020

Choose a reason for hiding this comment

lirantal Feb 1, 2020

Choose a reason for hiding this comment

lirantal commented Feb 1, 2020

lirantal commented Feb 1, 2020

JamesSingleton commented Feb 1, 2020

lirantal commented Feb 1, 2020

JamesSingleton commented Feb 1, 2020

lirantal commented Feb 1, 2020

JamesSingleton commented Feb 3, 2020

Francois-Esquire commented Feb 3, 2020

lirantal commented Feb 3, 2020

lirantal commented Feb 3, 2020

codecov-io commented Jan 28, 2020 •

edited