I'm reading the NPM docs about package-lock.json and my interpretation is that a committed change to it can never cause issues in the deployed version.
During the roll-out we run npm install which creates (or overwrites) the lock file anyway. In my mind, the lock file is more of a receipt of the state of the concurrent world while installing, rather than a pointer on how the installation should be performed.
However, I haven't been successful convincing my team that it is so. They feel uneasy relying on the statement above (not contradicting it nor arguing against it, just not entirely convinced to the degree that they would bet a testicle on it).
Is it at all possible that package-lock.json might affect the actual installation?
Since I'm new with the company, my track record of 10+ years has limited impact. And I'm myself humbly considering that even though the lock file never caused me any issues before, my experience might be irrelevant if the local environment is configured in a way I'm not familiar with yet. So I'm too cautious to bet my reputation as we're about to make a very important release.
In my mind, the lock file is more of a receipt of the state of the concurrent world while installing, rather than a pointer on how the installation should be performed.
Maybe I am interpreting your statement wrong but package-lock is a pointer for future installations in a way. See the general documentaion on lock files (different link than the one you shared), following statement from the above doc might be helpful:
This file describes an exact, and more importantly reproducible node_modules tree. Once it’s present, any future installation will base its work off this file, instead of recalculating dependency versions off package.json.`
A read on following discussion on this topic might be helpful to you too. Thanks!
Related
Most of the time wile installing new npm dependecies in a project, I get warnings and issues ( either low moderate or even crtitical).
And running npm audit fix, or fix by force doesn't resolve the issues.
Can I ignore them or should i fix myself ? Especially when it's about dependency tree
Warnings are here to tell that a bug have been found and will be probably corrected in a future release. Nonetheless, to avoid breaking a package, an old dependency (which can also have issue) can still be used. So, those who maintain the package have either the choice to rebuild their package without the problematic dependencies. Or they wait that the dependencies (or work on it) get corrected.
if you want to fix yourself every problems of every dependencies of every packages you are using, you will certainly need to reincarnate thousand & thousands times on earth to clean that mess xD
the best is to have the less packages possibles. But here are 3 points i'm used to check before deciding to use a package or not:
does it have a future ? (stars, download, last update)
are there a lot of peoples working on it ? (forks, issues, pull)
does it have too much dependencies ?
choose wisely can avoid you to fall into a devellopement nightmare.
I have been working on a big SQL based project that is taking an increasing amount of time and effort to maintain its versions. Lets keep it simple. I have three folders for each version of the code called Ver1, Ver2, and Ver3. All three version folders have the exact same filenames within it, but their content differs from version to version. If I make a change to a particular file in Ver3 that exists in Ver2 and Ver1, how can I use Git not to necessarily make the same changes in those other versions (not always practical due to partial rewrites for performance or logic changes), but to let me know that the other two versions of the file need to be updated in order to catchup to the Ver3? If Git isn't suited for this task, or if you have any experience with a similar issue, I would much appreciate any suggestions.
So, there is this cool package I've found but it leaves a lot to be desired. Since it made more sense to modify it, rather than build a new one myself, I changed the code in the corresponding source directory (C:\Users[my username].julia\v0.4[package name]\src). I made sure to modify not just the base.jl file, but also the [name of package].jl one so that there are no issues with dependencies or the new functions I added. I tried running the package several times to ensure that Julia doesn't spit out any errors or exceptions (the original package had some deprecated stuff, which I also remedied). Still, I fail to use the additional functionality of the package that I augmented. Any help would be greatly appreciated.
I'm using Julia ver 0.4.2, on a Windows 7 machine. As an IDE I use Notepad++. Thanks
I'm not exactly sure what you tried, but here's a guess as to what's going on: if you've already loaded the package in your julia session, edits to the source files won't take effect unless you explicitly reload the package. There are some good workflow tips here, and more explanation of the module system here.
However, for a newbie the easiest thing might be to quit julia and restart.
As far as making changes to a package, as Gnumic commented, your best approach is to make a branch and commit your changes there. Once you become convinced your changes represent an improvement, consider sharing your changes with the rest of the world.
I created an installer, deployed to our test environment and got an error due to a missing dll (it was not included in the wsx file). Is it possible to create a MSP patch to ship the missing dll or is it better to simply create a whole new installer?
I tried following various examples but I keep getting this error:
DEBUG: Error 2356: Couldn't locate cabinet in stream: media1.cab.
A patch can do anything an updated MSI can do, but it is merely a packaging and delivery mechanism that delivers an update in a more compact way. Hence you must actually create a full new version of your setup to be able to then package this new update as a patch.
Important: spend no time at all testing a patch before the full upgrade is working properly. This is a complete waste of time. It creates only mysterious errors and is a very common real-world time drain.
Unless your previous setup has gone to production and hence is "out in the wild", I wouldn't waste my time with a patch. Patches require a lot of time to create and even more time to test - there is a lot of added risk and complexity, and it is only intended to be a convenient way to deliver small updates such as what you describe without having to distribute a potentially huge, new MSI file. It is not common to use patches for UAT or QA testing unless your product is really huge and takes ages to install.
Personally I feel that MSI has failed entirely when it comes to patching. It should be an easy to use, value added feature, but it has become a hugely complicated, problematic issue in its own right.
Yes, you can add a missing file through a patch. Perhaps this article will help: http://wix.sourceforge.net/manual-wix2/patch_building.htm
When creating a patch you should always modify your existing installer. You don't create a new installer from scratch. Also, never remove resources from the new version. For a patch you should either modify or add resources.
Regarding error 2356, it seems like the original installation is somehow corrupted. You can try repairing the old version before applying the patch on it.
I know there are other applications also, but considering yum/apt-get/aptitude/pacman are you core package managers for linux distributions.
Today I saw on my fedora 13 box:
(7/7): yum-3.2.28-4.fc13_3.2.28-5.fc13.noarch.drpm | 42 kB 00:00
And I started to wonder how does such a package update itself? What design is needed to ensure a program can update itself?
Perhaps this question is too general but I felt SO was more appropriate than programmers.SE for such a question being that it is more technical in nature. If there is a more appropriate place for this question feel free to let me know and I can close or a moderator can move.
Thanks.
I've no idea how those particular systems work, but...
Modern unix systems will generally tolerate overwriting a running executable without a hiccup, so in theory you could just do it.
You could do it in a chroot jail and then move or something similar to reduce the time during which the system is vulnerable. Add a journalling filesystem and this is a little safer still.
It occurs to me that the package-manager needs to hold the package access database in memory as well to insure against a race condition there. Again, the chroot jail and copy option is available as a lower risk alternative.
And I started to wonder how does such a package update itself? What
design is needed to ensure a program can update itself?
It's like a lot of things, you don't need to "design" specifically to solve this problem ... but you do need to be aware of certain "gotchas".
For instance Unix helps by reference counting inodes so "you" can delete a file you are still using, and it's fine. However this implies a few things you have to do, for instance if you have plugins then you need to load them all before you run start a transaction ... even if the plugin would only run at the end of the transaction (because you might have a different version at the end).
There are also some things that you need to do to make sure that anything you are updating works, like: Put new files down before removing old files. And don't truncate old files, just unlink. But those also help you :).
Using external problems, which you communicate with, can be tricky (because you can't exec a new copy of the old version after it's been updated). But this isn't often done, and when it is it's for things like downloading ... which can somewhat easily be made to happen before any updates.
There are also things which aren't a concern in the cmd line clients like yum/apt, for instance if you have a program which is going to run 2+ "updates" then you can have problems if the first update was to the package manager. downgrades make this even more fun :).
Also daemon like processes should basically never "load" the package manager, but as with other gotchas ... you tend to want to follow this anyway, for other reasons.