scripting / feedlandInstall

Instructions for setting up a FeedLand server.
GNU General Public License v3.0
3 stars 1 forks source link

Trouble with NPM? #13

Open scripting opened 1 year ago

scripting commented 1 year ago

I have a new version of daveappserver to release, but I haven't been able to get my test server to update, and I imagine you all will have the same problem.

I updated the feedland package and daveappserver.

I got email confirmations from NPM that they updated.

If you go to their pages, you can see they have updated: feedland, daveappserver.

But when I do a npm update on the test server, nothing changes.

I tried removing the node_modules directory and doing an npm install, and I get the old version of feedland.

I'm stuck. I don't know what to do. We all should be testing the latest software, and I want to do some more work on daveappserver to allow the prefs.json file to be stored in S3 as an option, to make hosting of FeedLand work on larger systems.

Please try updating, and if you have any ideas of what I should do differently, I'm open to new thinking.

scripting commented 1 year ago

I seem to have gotten past this problem, but I have no idea why.

Here's what happened.

I started off this morning trying to get my test FeedLand server on my local machine to run in the debugger.

First step was to get the new version of daveappserver installed. I updated the feedland package, and then did an npm update on the test server folder, but it didn't load anything new, even though there was a new version of feedland in the NPM database.

I then edited package.json and set the version of feedland to "^0.5.2" which was the last version I published. This worked. I got the new version of both daveappserver and feedland.

I did some debugging, and needed to update both feedland and daveappserver, and did the same thing again, and once again it worked, this time setting the version to "^0.5.3".

For the next change, I decided not to change the version in package.json, and now it decided to let me have the new version without any trickery.

Worked for the next version.

I don't know what this means for everyone else, but I am now finally unstuck, and am debugging the new code that stores the static files in S3 instead of the local file system (as an option, will document once the feature is working properly).

Onward! :-)

scripting commented 1 year ago

Okay -- we're back to the bad behavior.

I just updated both feedland and daveappserver, yet when I did an npm update, I didn't get the new daveappserver.

So I did this npm install daveappserver and I appear to have the latest version, so this is another possible workaround until we get this down.

chriszarate commented 1 year ago

There are a few things going on here, but I wouldn't be able to answer definitively without seeing the the project folder on your test server. Regardless, I think I can point you to some best practices that will help you moving forward.

The key issue here is that the purpose of npm update isn't to update all packages to their latest version. Instead, its purpose is to update your project's dependencies while respecting the semver contraints you specify in package.json:

This command will update all the packages listed to the latest version (specified by the tag config), respecting the semver constraints of both your package and its dependencies (if they also require the same package).

Therefore, if your package.json contains an exact ref like 0.5.1, running npm update won't do anything, because you have specified the exact version you want—and you already have it.

I then edited package.json and set the version of feedland to "^0.5.2"

This probably explains why updates started working for you. A caret-prefixed ref indicates that you are willing to accept minor and patch updates and npm update will happily apply them.

However, the * version refs used by feedland's package.json (and in general across its subdependencies) also come into play—along with package-lock.json, which always records the exact versions installed at any given time regardless of the version ref used in package.json. While semver's spec might lead you to believe that * results in a policy of "accept any update", NPM's interpretation is different:

* Matches any version

Again, NPM's primary goal is to respect semver constraints and avoid conflict among your various dependencies. If you use npm install to update a dependency, a * version ref in a subdependency (like for daveappserver) will generally result in NPM keeping the currently installed version in order to avoid conflicts. Since you specified via * that you are happy with any version, NPM assumes you are fine with that.

Providing a more specific semvar constraint will lead to more predictable behavior. I would recommend exact refs or caret refs.

Exact ref workflow

In this scenario, you always specify the exact version you want. Explicit and leaves a good history in your shell.

# in `daveappserver` package
# commit changes
npm version patch
npm publish
# in `feedland` package
npm install --save-exact daveappserver@0.6.18
# commit changes
npm version patch
npm publish
# on test server
npm install --save-exact feedland@0.5.8

Caret ref workflow

In this scenario, you receive minor and patch updates via the semver behavior of ^. For this workflow to work, you must first update the package.json of each of these packages to use caret version refs and publish the result. I.e., this will only work after your published packages no longer use * version refs.

# in `daveappserver` package
# commit changes
npm version patch
npm publish
# in `feedland` package
npm update
# commit changes
npm version patch
npm publish
# on test server
npm update

Hope this helps!