Figure out Wasp's package.lock.json story

[Martinsos]

We want to offer same guarantees as package.lock.json does, which is ensuring reproducible builds.

How do we do that with Wasp? Do we copy the package.lock.json files up from generated project files to the source? Or do we use some other abstraction on top of it? Should we use yarn instead od npm since it allegedly has better support (cross platform, fevent issues are avoided by yarn but unsolved by npm).

[sodic]

We could consider splitting Wasp into two folders:

• .wasp/ - This one remains hidden and contains the build artifacts. Users to not include it in version control.
• wasp-info (with a hopefully better name) - A visible directory containing all the persistent stuff (package-lock.json, migrations, and anything else we need in the future). Users would include this one in their version control.

I have a feeling we'll start encountering this problem more often as time goes by and we start integrating with more and more packages.

[Martinsos]

For grouping all the files that we generate but need to be part of the project anyway and be committed? Sounds good! Maybe a bit cooler name but this one is also not so bad!

…

On Mon, 4 Jul 2022, 12:01 Filip Sodić, ***@***.***> wrote: We could consider splitting Wasp into two folders: - .wasp/ - This one remains hidden and contains the build artifacts. Users to not include it in version control. - wasp-info (with a hopefully better name) - A visible directory containing all the persistent stuff (package-lock.json, migrations, and anything else we need in the future). Users would include this one in their version control. I have a feeling we'll start encountering this problem more often as time goes by and we start integrating with more and more packages. — Reply to this email directly, view it on GitHub <#559 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALXFB2YENVDEE63NKPKDYDVSKZALANCNFSM5TEE3AWA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Martinsos]

Related to #734 somewhat.

[Martinsos]

Related issue, where the fact that we don't have package-lock.json for our server code (framework code, so generated by us) caused issues: #1724 .

[Martinsos]

Btw, one thing is storing package-lock files, but we actually also have to be able to use them! This is normally done with npm ci instead of npm install, but this is not as straightforward in Wasp.

So, if I want to run my Wasp in CI, and I want to install deps from package-lock.json, but not only the top level one (client code), but also based on package-lock.json's of framework code (web-app and server), how can I do that? What should probably happen is that npm install's that Wasp is running for us in the background should be replaced with npm ci's instead, in such situation. But we don't have a command for that at the moment. So we should likely have something like wasp start --ci or maybe CI=true wasp start or something similar. Might also be important for some other commands than just wasp start, if they are also running npm install, which is why probably having wasp checking for a CI env var is the best option, as we can have that info used easily in whatever piece of waspc code we need and modify behaviour based on it.