Workflow: Build and run my apps on your machine

Hey! Thanks for posting these videos, they are very interesting to see how you work :). I have a couple of comments/questions.

About installing Node, one problem I’ve found working with different projects is that not all of them work in the same version of Node. I usually solve this using nvm — Node Version Manager. It allows you to have multiple versions of Node in the same machine. You can also add a .nvmrc file in your repo an then people only need to run nvm use in order to have the same Node version as you. For people who is not using nvm, you can also use engines.node in package.json.

I am surprised looking at your package.json, it looks very different from most projects I’ve come across. In particular, how come you’re not indicating any specific versions for your dependencies? The package-lock.json you mention is actually quite useful, because it stores the exact versions of the dependencies you’re using. Without doing this, if one of your dependencies publishes a new version it could break your code. And maybe you notice now, but imagine that you don’t touch an app’s code base for 5 years, then it’ll be almost impossible to make it work.

You mention that you do a lot of testing, but I don’t see any Continuous Integration (like Github Actions). That means that you rely on running tests in your machine before pushing new code? I think it’s a good idea to use CI, not only because it tells you if something is broken in case you forget to run the tests, it also makes sure that your code actually works in an isolated environment. It would be possible that your tests are passing locally, but you rely in some global dependency that you weren’t aware of. I still have to watch your video on testing, sorry if that’s already answered there :).

Thanks for watching and sharing your comments @noeldemartin. I think all of your suggestions make total sense…

Would definitely be better to specify a node version. I didn’t know about engines.node and that feels better than having more dot files. I may set this to whichever one is running on my machine.

I don’t specify package versions because of a somewhat naive intent to ‘keep it working with the latest versions’. Of course, the longer I wait between updating packages, the more likely there will be issues. And there have been issues several times so far, sometimes small and sometimes large, but I managed to figure it out. I don’t recommend my approach for other projects, and I’m not sure I will keep doing it this way, but it works for me so far and I know I can always drop down to specifying specific versions.

There is no CI because I don’t know how to set that up and have focused on other things, but I would love to do that. Would be an integral part of testing.

The problem here is not just for yourself, but for contributors as well. Imagine that a breaking change has been released in some dependency; you won’t notice until you update your dependencies locally. But a contributor who’s trying to run your code today will. And I think the less barriers you have for contributors, the better. You’re already doing great with the videos :).

Ok, I’ve already done it in a bunch of projects, so maybe after watching the videos about testing I’ll open a PR to show you how to do it. I’m not making any promises though! But feel free to ask me if you eventually want to do it.

1 Like