kinow commented on PR #2043:
URL: https://github.com/apache/jena/pull/2043#issuecomment-1769271756

   > If we regenerate yarn.lock (by "rm yarn.lock; yarn install" - is there a 
better way?) won't dependabot changes be lost?
   
   Not sure. We'd have to look at the transitive dependencies (babel deps are 
not listed in our package.json, I think). The lock contains the sate of 
dependencies at one point in time.
   
   If we delete the lock file, and re-create it, that will be a new point with 
the latest dependencies, which probably don't have the version with the 
security issue.
   
   If you'd like we can try changing our `dependabot.yml` to use that setting 
in versioning-strategy: 
https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#versioning-strategy.
   
   That should make dependabot to update the lock file and also `package.json`. 
But I am not sure about dependencies that are not in our list of dependencies. 
I don't think it will add something to ... resolutions? Can't recall the name 
of the key used to pin down versions. But maybe it's worth a shot if you prefer 
to use package.json.
   
   I normally don't delete the lock files. 
   
   >I tried yarn upgrade-interactive - build failed - I get a lot of 404's 
(below)
   
   Never tried that utility of yarn. I just run `npx ncu ...` to ask npm to 
check and update dependencies from the NPM registry, then update my 
dependencies in `package.json`, freeze the dependencies again in my lock file 
and commit it. Then dependabot keep that lock file free of security issues 
(which should be fixed in the transitive dependencies, otherwise I think 
Dependabot gives one of those error messages "Dependabot is not able to 
generate a pull request for this issue etc etc").
   
   Sometimes a dependency just cannot be upgraded, because it depends on 
another version that conflicts with another library already in use. In cases 
like this we can only wait -- unless it is in Vue, for example, which would be 
critical as that's used in the final apps -- for issues in the dev libraries 
it's normally fine.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to