deno.lock multiple entry point best practices
Hi, I just upgraded to 1.28.0 and realized that lock files are here by default for deno.json config projects. I figure that means its time I adopted lock files. So I wanted to open a forum about best practices. I have read this doc https://deno.land/manual@v1.28.0/basics/modules/integrity_checking, which is a good start. I know at least that a lock file should be checked into git (which is less confusing than w/ node, where lock files change per OS and their advice on version control is pretty fuzzy.
Here is my remaining question though, what happens when I have multiple entrypoints? Specifically, I am looking at this repo I own https://github.com/andykais/sqlite-native. I have three main module entrypoints:
1. src/mod.ts (this is what lib users will use)
2. test/*.ts (this is for running tests)
3. deps/compile.ts (this is a build script for building/upgrading the sqlite.so shared lib)
should I have three separate lock files?
Interestingly, it seems like deno is smart enough to only add to the lock file if I do not specify manual locations (I would assume different entrypoints would cause the deno.lock file to thrash in version control. What is the best practice here, specify multiple entrypoints, or just let deno manage one lock file?
Another, related question, does the lock file do anything as a remote module, or is it only used locally? The docs seem to imply the latter, but I was hoping someone here could confirm.
1 Reply
I also have the same issue. I have a cli and webserver entrypoint to the same codebase