turbo
turbo copied to clipboard
vercel
Consider publishing Go modules for the parsing of lock files
Describe the feature you'd like to request
I would like to ask whether the Turborepo could consider publishing the code for managing lock files, such as reading the lock files and extracting the list of dependencies out of it
I am asking this as I want to add support for PNPM lock files in a vulnerability scanner that is used in Gitlab CI and I thought it would be nice to be able to reuse the Turborepo relevant code for this.
I did have a go at it myself a while back: https://gitlab.com/weyert-tapico/gemnasium/-/blob/add-pnpm-lockfile-parsing/scanner/parser/pnpm/lockfile.go but would be nice if I could leverage the knowledge of this project
Describe the solution you'd like
Publish the lock file parsers as Go modules
Describe alternatives you've considered
Write my own code to parse PNPM lock files
I'm a little hesitant to start publishing these as a stand alone library since I've already made a fair amount of breaking changes to them since they were added. If you just need the ability to list out all of the packages in the lockfile, I think that would be fairly stable though. Either way, I probably won't get to this until we wrap up support for npm.
@chris-olszewski I was wondering if you know whether this license [1] is compatible with your license inn such a manner I can vendor the pnpm lockfile parsing in the referenced project. To me, the paragraph quoted below makes it should be, right?
For all third party components incorporated into the GitLab Software, those components are licensed under the original license provided by the owner of the applicable component.
[1] https://gitlab.com/weyert-tapico/gemnasium/-/blob/master/LICENSE
@weyert I'm no lawyer, but our intent with the MPL license is to ensure that all changes and improvements to our code are available to its users, in perpetuity.
For vendoring (since we are realistically not going to go through the effort of extracting these as publishable modules given the direction we're heading with Rust) I would recommend an approach of forking to an MPL2 project, stripping it down to just those components, keeping that isolated, and then importing that as "just an import" into any other codebase.
I believe that ensures license compliance while also keeping the dependent project properly insulated from our license.
Again, not a lawyer, but that's an approach that would not cause me to go ask our lawyers to make sure everything was okay. 🤷♂️
Also, closing this since we're not going to publish the modules, but there is a recommended path forward here.
(Note that in turning them into modules we might adopt them if things have stabilized!)