2

I am having a certain conundrum and can't seem to find the correct solution.

The current project I am working in uses npm to manage our packages. We haven't been using package-lock.json for a while, but need to re-include it.

The problem is, we have a few custom packages (ex. "my-components") that we install via npm that contain our code for components, etc. For these packages, we always want to include the latest version when doing an "npm install".

My question is, is there any way to exclude certain packages for the package-lock.json? Or is there any other soution to this problem?

Ideally, all packages other than our custom packages would be locked to a specific version, and then our custom packages would always be installed from latest.

EDIT: To clarify, the main issue I am having is that for development, we're not pulling specific versions of our custom packages. We are just pulling whatever happens to be on the #dev branch. For specific releases we have a version number, but we're fine there. We want to be able to have our custom packages say "Always pull whatever happens to be on the dev branch whenever an npm install is ran" but we want all of our other packages to be locked to a specific version.

naturalrogue
  • 41
  • 5
  • in package.json you can specify version range ^1.X.X will give you the latest allowing major releases while ~ will only allow latest minor release. – digital-pollution Oct 10 '18 at 14:47
  • 1
    should have added the package.json if updated will trump package-lock. So if you want to roll out the latest version of something just update it in the package.json, test it locally and recommit. The point of the lock is to keep everyone in a project on the same version. – digital-pollution Oct 10 '18 at 14:58
  • That's helpful information! So in this case, my package-lock would ensure that all packages, except my "my-components" package would stay exactly the same, as long as I update "my-components" in the package.json? – naturalrogue Oct 10 '18 at 15:00
  • @digital-pollution I added an update to the question above, to clarify exactly what I am asking. Do you have any thoughts on that? – naturalrogue Oct 10 '18 at 15:08
  • Yes, updating the allowed version explicitly (or ranges) for components in your package.json is always the safest and best option. I would recommend allowing minor releases ( ~X.Minor.X ) automatically but requiring a dev to manually test major releases. – digital-pollution Oct 10 '18 at 15:13
  • in answer to your edit I'd say set the specific versions in package.json and set your custom components to "latest" – digital-pollution Oct 10 '18 at 15:21
  • Gotcha. We were hoping to avoid having to update the version of our custom components package every time someone pushes a change, since we have a huge number of changes to the package every minor release, but I can see how that would be the best solution here. Currently, when working in the dev environment, we're just targeting the dev branch of our package in bitbucket and pulling whatever happens to be there, but that conflicts with the package-lock idea. – naturalrogue Oct 10 '18 at 15:23
  • Yeah a lot of people turn it off in dev as it requires a bit of micro-management and just use it for safe production builds ( big controversy when it was introduced in node 5.x ). – digital-pollution Oct 10 '18 at 15:27
  • Makes sense. Thanks for taking the time to help me out, I really appreciate it! – naturalrogue Oct 10 '18 at 15:30

1 Answers1

0

If it is only for development, you might use npm link. It will basically create a symlink to the other package, that you can keep updated from its own folder.

For instance if you have two packages, my-components and main-project, where my-components is a dependency of main-project, and let's assume there are both in the ~/projects directory.

From the ~/projects/my-components source folder, run npm link.

Then from ~/projects/main-project run npm link my-components.

You can now develop those two projects in parallel.

Anthony Garcia-Labiad
  • 3,531
  • 1
  • 26
  • 30