This topic was automatically generated from Slack. You can find the original thread here.
One thing I’m curious about is why pnpm-lock.yaml generated so many changes?
I was tempted to revert changes because they seemed irrelevant but then the branch push controls told me to commit it.
yeah great question. We have internal workflows automate part of the new app publication process. When a new app is released, we immediately build a new dir under components/ with a package.json and an app file to add the scaffolding for that app, making it simpler for people to start developing components for it.
At the same time, all app code is published as its own npm package (e.g. @pipedream/discord, @pipedream/notion), managed via pnpm. So when you pull the latest changes from master, you’re getting those automated commits, and since pnpm watches for new dirs, it’s adding them to the lock file.
Ideally the workflow would handle committing the changes to pnpm-lock.yaml as well since the change is tied to that — have y’all looked into that? Not urgent but can chat you separately about that workflow.
Definitely, let’s chat about it and get it done. I agree it’s confusing.
Probably the most inconvenient part of it is that I’m having to resolve pnpm-lock merge conflicts multiple times while my PR is open until it’s finally accepted.
I just pushed a fix for the main issue. You may still see this happen from time to time due to other reasons, but for the most part, our new app publishing workflow should now also update the pnpm-lock.yaml file for each new app, which should eliminate the main reason people were seeing these merge conflicts in the past. Note, if you’re on an older branch, you may need to merge master now, to make sure your lock file is in a clean state.