What will happen if the "package.json" version is not followed in sequence and the same version is repeated in the history with different code-base?
Let us suppose:
Project-XYZ package.json version 1.0.0 is published with the changes in the files (file1, file2)
Project-XYZ package.json version 1.1.0 is published with the changes in the files (file2, file3)
Project-XYZ package.json version 2.0.0 is published with the changes in the files (file3, file1)
Project-XYZ package.json version 1.0.0 is published with the changes in the files (file4, file2)
Project-XYZ package.json version 1.0.1 is published with the changes in the files (file5, file1)
Project-XYZ package.json version 1.0.2 is published with the changes in the files (file2, file1)
Project-XYZ package.json version 1.1.0 is published with the changes in the files (file1, file2)
Project-XYZ package.json version 2.0.0 is published with the changes in the files (file4, file5)
package.json version 1.0.0 is published twice with the different codebase, should this work or would it cause any problem.
I am actually experiencing an error called Timeout._onTimeout after particular commit in the Gitlab pipeline but the only difference I could see in the code was this versioning order, it is certain that the engineer missed the actual version and tried pushing on the older version only and since then on the sequence continued for the same versions in the history repeating with the different codebase.
should this cause any problem ? have any of you come across such a scenario?
Please help. Thanks in advance!
I found an answer on npmjs docs and it says:
Fails if the package name and version combination already exists in the specified registry.
Once a package is published with a given name and version, that specific name and version combination can never be used again, even if it is removed with npm-unpublish.
As of npm#5, both a sha1sum and an integrity field with a sha512sum of the tarball will be submitted to the registry during publication. Subsequent installs will use the strongest supported algorithm to verify downloads.
So, clearly we can't have such versioning and I will try and fix the above issue moving the code-based to new and unused versions.
Related
I'm trying to use bower the package management to add new modules to my project.
I am using travis for continuous integration
Travis CI throws an error
error: pathspec '2.4.1' did not match any file(s) known to git.
This is issued by the keyboardjs module with 2.4.1 version, not sure what would be the optimal workaround this? If you check the package.json of the keyboardjs Github It's using the version 2.4.1 aswell.
My package json line for the 2.4.1 version of keyboardjs
#bower_components/keyboardjs": "RobertWHurst/KeyboardJS#2.4.1",
What is contained in the package.json file is irrelevant. If you are using a git URL you have to provide something that references a commit.
You can see on the tags page that the tag is called v2.4.1. So:
RobertWHurst/KeyboardJS#v2.4.1
// ^
Let's say we have 3 packages with the following dependencies:
C -> B#^1.0.0 and B -> A#^1.0.0
(module C depends only on module B version 1.0.0 and above; module B depends on module A version 1.0.0 and above;)
Now I'm doing the following steps:
npm-install in module C (result: node_modules contains A#^1.0.0 and B#^1.0.0)
npm-publish of higher version of module A: A#^1.0.1
npm-update in module C (result: node_modules contains A#^1.0.0 and B#^1.0.0) --- A module didn't changed!
But, if i'm cleaning node_modules and then npm-install module C again, i'm getting that node_modules contains A#^1.0.1 and B#^1.0.0
Is there any way i can get full updated node_modules without delete and install it again?
If not, what is wrong in the way I manage the dependencies? I don't want explicitly add all the dependencies trees so node-update will work
npm update respects semantic versioning, it will not update major versions of packages if you have a ^ dependency.
^ on a dependency literally means that it's only fine to update up to a minor version - since major versions contain breaking changes.
This command will update all the packages listed to the latest version (specified by the tag config), respecting semver.
From the docs
After updating NPM to version 5, I found package-lock.json file with package.json.
What is the difference between this two files?
What are the advantages of package-lock.json?
A package.json file: lists the packages that your project depends on. allows you to specify the versions of a package that your project can use using semantic versioning rules.
According to the npm docs,
package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json . It describes the exact tree that was generated, such that subsequent installs are able to generate identical trees, regardless of intermediate dependency updates.
This file is intended to be committed into source repositories, and serves various purposes:
Describe a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.
Provide a facility for users to "time-travel" to previous states of node_modules without having to commit the directory itself.
To facilitate greater visibility of tree changes through readable source control diffs.
Basically package-lock.json is used to optimize the installation process by allowing npm to skip repeated metadata resolutions for previously-installed packages.
Before npm 5.x.x, package.json was the source of truth for a project. What lived in package.json was law. npm users liked this model and grew very accustomed to maintaining their package file. However, when package-lock was first introduced, it acted contrary to how many people expected it to. Given a pre-existing package and package-lock, a change to the package.json (what many users considered the source of truth) was not reflected in the package-lock.
Example: Package A, version 1.0.0 is in the package and package-lock. In package.json, A is manually edited to version 1.1.0. If a user who considers package.json to be the source of truth runs npm install, they would expect version 1.1.0 to be installed. However, version 1.0.0 is installed, despite the fact that v1.1.0 is listed is the package.json.
Example: A module does not exist in the package-lock, but it does exist in the package.json. As a user who looks to package.json as the source of truth, I would expect for my module to be installed. However since the module is not present in package-lock, it isn’t installed, and my code fails because it cannot find the module.
Read more about package-lock.json in the Official npm Documentation!
package.json records only your direct dependencies and their versions.
package-lock.json records not only your direct dependencies and exact versions, but also those of all dependencies of your dependencies - the entire dependency tree, in other words, with exact versions.
It's the fact that package-lock.json records the exact versions of all dependencies of a project, including sub-dependencies, that ensures that builds will be identical each time. (This is why npm ci bases its build on package-lock.json, not package.json.)
Builds based on package.json (as with npm i) cannot guarantee that all sub-dependencies are the exact same versions each build (e.g., if the subdependency of one of your dependencies releases an update, but the version of your direct dependency doesn't change), even if exact version numbers for direct dependencies are specified in the package.json.
I'm having a problem where some recent update (in the last week) to a dependency of a dependency is causing a breaking error in Safari. I have all of my versions set to exact in package.json but their dependencies are obviously going to pull using semvar version ranges. My old package-lock.json has invalid checksums now so that isn't working.
How do I rebuild my node_modules using the lowest specified versions of dependencies (ignoring semvar/version ranges)? I want to get the exact specified packages for all dependencies without automatically pulling a more recent version.
By way of example: foo" = "~1.0.1,
I'm having problems understanding how I to use dynamic revisions of Ivy effectively in my Java projects.
Currently, I have the following layout:
lib-a
revision: 1.0.0
status: release
dependencies: none
lib-b
revision: 2.0.0
status: release
dependencies: lib-a, rev 1.0.0
project-a
revision: 3.0.0
status: release
dependencies: lib-b, rev 2.0.0
project-b
revision: 4.0.0
status: release
dependencies: lib-b, rev 2.0.0
That means I always keep the status to release and use explicit version numbers.
If I would change lib-a during development, say lib-a, this is quite painful.
I save the changes in lib-a, update the revision in the ivy file to 1.0.1 for a minor change. Then i need to update the dependencies of lib-b to announce the revision 1.0.1 of lib-a. Now I could either update the revision of lib-b and also project-a because project-a is the executable and contains integration tests which I need to run.
The second way is to re-publish lib-b with updated dependencies but same version. This usually works with ant on command line but not for NetBeans with ivy-beans plugin. They still use a cached version of the ivy file of lib-b. So I need to clean to local cache to make it work.
I use a common build-ivy.xml ant script that is in our SVN repository for all projects. Each project has a build.xml in the project's root that most of the time simply includes the build-ivy.xml. Sometimes necessary tasks are added or overwritten.
I've just read here and here that the solution might be using dynamic revisions.
As far as I understand it, I would set the revision in all ivy files to integration-latest and set the status in all ivy files to integration. Then, ivy would always resolve the latest version automatically.
But what would I set the revision of my modules to? Omit it completely?
How would I create a release version? Do I need to change all ivy files and set the status to release or would I perform a deliver task before publishing a module with overwriting the status to release if possible?
I would suggest reading the following tutorial on multi-module projects in Ivy.
http://ant.apache.org/ivy/history/latest-milestone/tutorial/multiproject.html
ANT builds traditionally are big and monolithic. what you need to do is emulate Maven's way of splitting a large project up into a series of smaller builds. Each sub-build publishes it's artifact into ivy's local repo.
Ivy has lots of useful tasks for this kind of structure:
buildlist - Called from your overall main build file. Use to look into each sub-module's ivy.xml and determine the proper build order (Some modules depende on others)
buildnumber - Looks at what is already published and generate the next build number in the sequence
publish - Push artifacts into local repo (or a foreign one, if configured in the ivysettings.xml file)