Don't track compiled production assets in git

[mattheu]

Ideally, we would not have built assets tracked in git.

We have a script that builds production versions when you run npm version, and they will be included in a version published on NPM, which is the recommended way to use this file.

What do we lose. Right now you can just install from git... and that won't be possible. I was thinking about whether it was possible to include them in tagged releases only? Or a release branch? But i'm not really sure if this is necessary TBH. Is anyone using this project in this way?

[tomjn]

Do we still want the package lock file?

[mattheu]

Do we still want the package lock file?

@tomjn not sure what you mean... Yes, I think we do still need it?

[kadamwhite]

+1, @mattheu.

I do think it would be useful to set up a build-to-branch or build-to-tag action, we have a couple to choose from: H2 has a build-to-release-branch action, so we could have a branch which tracks main but includes built assets; and we've also set up release actions before which add built assets when you create a version tag (and publish that as a release). But I don't think adding such a workflow is blocking.

[kadamwhite]

I can't speak for @tomjn but I'm guessing he was thinking that if we're not including built assets and treating this only as a set of components, omitting the package lock might remove some friction around resolving package updates. I've heard a number of arguments over the years that lockfiles should be omitted from dependencies, and only used in the parent app or build system.

[tomjn]

I don’t really remember, but I do have 1 qualms: - with WP 6.4 there will be updates packages but this package lock might prevent those being used unless it’s regenerated on every update, but that might not be how this works - dependabot is this repos biggest contributor and all it does is update a lock file, I’m not seeing value in either On that note though, should this be considered a major breaking change? Are any other assets actually relying on the built JS files for this?

…

On Wed, 25 Oct 2023 at 22:11, K Adam White ***@***.***> wrote: I can't speak for @tomjn <https://github.com/tomjn> but I'm guessing he was thinking that if we're not including built assets and treating this only as a set of components, omitting the package lock might remove some friction around resolving package updates. I've heard a number of arguments over the years that lockfiles should be omitted from dependencies, and only used in the parent app or build system. — Reply to this email directly, view it on GitHub <#148 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAOLZ7FOCSJWJPY2LWHWHLYBF57PAVCNFSM6AAAAAAY3F6WLWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBQGA3DEMBVGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[tomjn]

I've approved, we can always remove the lock file in another PR

[mattheu]

Ah I see what you're saying - remove the lock file from the distributed version. OK that makes sense. But yeah, lets do a separate PR for that as it's a slightly different change.