Remove esbuild from devDeps but keep testing in CI, fix #139 #149
Conversation
|
Great job! Btw: I just noticed the "Checks" tabs on this commit. I haven't used this kind of CI- flow in the past. Looks solid. Is Also, I'm not familiar with these pnpm/bun lock files. Can you explain them to me (like I was 10 years old) and what should I do about them? |
Revert unnecessary changes of bun.lockb in PR #149
The CI / CD can include many things, for example:
But according to nuejs CONTRIBUTING.md , I'm not sure which of them you want for it, for keeping its simplicity (I love simplicity too 😂 ) |
|
We might need to circle back and decide on a policy for I did see this plugin for vscode where you can preview the lock file changes; For now we should perhaps add 'bun.locb` to .gitignore to make our current temporary decision explicit, otherwise it could confuse a new developer checking out the code and running the tests for the first time preparing to submit a small branch PR, just to get going. (that's how I found the lock file and this thread by the way.) New devs to the project running |
|
Configure git to show the diff & other details like clear text lock-files: https://bun.sh/docs/install/lockfile (details, git, etc.) Also see this comments here: #150 (comment) (general comment) But I can also see your concerns regarding new developers and binary lock-files in general. Maybe we could add to the developer guidelines, that the lock file should be used for installation (, also in tests on this end)? Just thinking aloud... |
|
@nobkd To solve the problem of "least suprise" it would also be quite ok to simply also check in the lock file, assuming that if I run a build bun would generate the same deterministic binary lockfile. easy enough to test; if that works that also makes the scary "why am i suddenly seeing a changed file that should be under source control" warning. i.e. I should have mentioned above another simple solution is also to just check the file in to source control. Thanks for the links to #150 those were quite helpful. Bun looks quite smart, and I can totally understand why the build is so much faster, makes sense when you read the explanations. My "thumbs up" above isn't me saying we should cron job updating lock-file; I need to get more /deeper involved in the project before I can comment otherwise I risk saying stuff without important context and understanding. My thumbs up means I think some discussion around your idea is valuable. Doing nothing, or the simplest and smallest something, (like, just checking it in) will at the very least give us more information (data) to make a better decision on. |
|
@goblinfactory let's talk about this tomorrow! |
fix #139 (comment)
Below is output from [[ git diff 16334ea 4e0cb43 -- bun.lockb ]], ref: https://bun.sh/docs/install/lockfile
I can't prevent the unrelated version change (marked@^9.1.6), if you guys know how to improve pls tell me ;)