A XSS vulnerability was fixed in the marked library, with no new version yet bumped to npm. What are my options here to update my application with this fix (i.e. applying the fix, without manually adding the updated library code unmanaged by NPM)?
The commit can be found here.
https://github.com/chjj/marked/commit/cd2f6f5b7091154c5526e79b5f3bfb4d15995a51
I'd prefer to keep using NPM to retain control over versioning of packages in the project.
Is there a way to do an NPM install on the (specific) github version including the fix?
Related
I have a package, which offers basic utilities. It has a dev-dependency on a tool, which helps build it. That tool in turn needs features from the package.
The problem is, that during development of the package, the dependency of itself gets resolved to the local workspace, not fetching it from a registry - which obviously won't work, for two reasons:
it isn't built
the version isn't bumped yet, but there may already be breaking changes
Personally, i don't know why this behavior is desirable in the first place, but how do i disable it, forcing a resolution to the registry, fetching the current latest published version?
Using yarn 3.2.0 with pnp (could not see any related changes towards 3.2.1, therefore imho irrelevant)
The behavior can be disabled via enableTransparentWorkspaces: false in yarnrc.yml.
After additional research, i found yarn-2-berry-npm-protocol-switches-to-workspace-resolution, which links to a related github Q&A, where the answer is given. Sadly, it never got accepted on github, nor propagated to the related SO question, so i'll keep this one here.
I am in the process of modularising my app using Swift Packages and some of these modules will be useful for future apps so I have created standalone Packages and added them to the main project as dependencies.
As recommended, I am using semantic versioning and have tagged the commit as per the Apple documentation (see here) and pushed to my Github account.
When I attempt to add this package to my app using version rules ("up to next major version") the dependency does not seem to be resolved properly; the code cached locally only contains a bare package without any of the code I subsequently added.
If I remove version rules and use commit rules instead, I get the whole package as expected but that may cause problems with compatibility in the future as the package evolves.
Checking the version control in Xcode and directly on Github shows that the version tag 1.0.0 is present and associated with the last commit which is puzzling. The steps taken in an attempt to resolve the issue are as follows:
force push package (including tag) to GitHub
remove version control from package by deleting .git file and adding version control, committing, tagging then pushing to remote
reset package caches
clear derived data
close and restart XCode
None of the above work and I thought initially that I was not doing things in the correct order. However I'm particularly puzzled that removing version control then setting it back up again (with the code codebase in a complete state at this time) didn't work as the bare-bones template package was never pushed to the remote in the first place. I don't understand how can Xcode be still retrieving it. IMO this suggests there's a cache somewhere it's falling back to (despite being told to clear the cache) but I stand to be corrected.
Screenshots of the remote (showing the correct tag) and states of the Xcode package dependency using branch rules and version rules attached.
I am using Neos CMS for my website. Now I am trying to update the CMS via composer update. Inside my project I installed a package that is now abandoned. That resulted in a failed update because the composer.json inside the package does not require the newer version of the CMS. Basically I just need a way to completely ignore that package while composer is updating. --no-dev did not work. That resulted in: Running update with --no-dev does not mean require-dev is ignored, it just means the packages will not be installed. If dev requirements are blocking the update you have to resolve those problems. Would be great if someone has an idea.
If the source of the abandoned package is still available, you may create a fork of it, change the requirement settings and then include your fork like described in How to require a fork with composer?
A much better way would be to exchange the package with something else which is still maintained. If you rely on the functionality of this package in your project(s), it may be worth to maintain an updated fork of it on your own.
Gradle's dependency management system stores downloaded artifacts in a local Maven cache. When a build requests that same dependency again the dependency is simply retrieved from the cache, avoiding any network transfer of the artifact.
I'm trying to replicate this behavior with NPM for building JavaScript projects. I was expecting NPM to support a global node_modules cache, but installing a package "globally" in NPM has a different meaning => the package is added to PATH so that it can be used as a CLI tool.
Reading the documenation for npm install, the standard behavior is to install packages into a local node_modules directory. But this would mean many duplicated packages on the system wasting valuable disk space. It also poses a problem for doing clean production builds, since ideally the node_modules should be blown away each time.
Does NPM support something like the Gradle's Maven caching? Documentation on NPM cache doesn't make it any clearer how this is to be used. What's more, it's not obvious if a caching strategy with NPM is safe across multiple parallel builds.
This seems like such a basic requirement for busy CI environments that it must have been solved before. I found the npm-cache tool which seems to offer this support, but it would be much better if caching was supported natively in npm itself.
Thanks!
IMHO it is a pity that the makers did not learn from things like maven that have already been there. If you are doing microservices and have many apps on your machine and you might also have multiple branches or a local jenkins you will have each dependency N*M times on the disk what is an extraordinary waste of disc-space and performance. So you have to be aware that Java or .NET/C# are mature ecosystems while the JavaScript ecosystem is still in the childhood with lots of flaws and edges. But JavaScript is evolving fast so lets hope for the best. Feel free to discuss your pain with the npm makers (https://github.com/npm/npm/issues/).
However, a partial cure comes if you go away from npm and switch to yarn: http://yarnpkg.com/
NPM Cache already comes bundled with NPM out of the box(listed under cli commands). And its main utility is to avoid the network transfer of the same package over and over.
Regarding the duplicate packages issue, as of npm v3 there has been an effort in terms of finding ways to deduplicate dependencies. But it still does not work exactly like Gradle since it is still possible to end up with duplicates of the same package in your node_modules folder.
Per NPM documentation:
Your node_modules directory structure and therefore your dependency tree are dependant on install order
Although a fresh npm install from the same package json always produces the same dependency tree:
The npm install command, when used exclusively to install packages from apackage.json, will always produce the same tree. This is because install order from a package.json is always alphabetical. Same install order means that you will get the same tree.
So at least there is a way to get consistent dependency trees, albeit there's no guarantee it will be the most efficient one. At least those differences do not interfere correct functioning of NPM.
Hope that helps.
We're using composer, satis and SVN to manage our in-house PHP libraries.
We commit changes to SVN trunk during development, then tag versions (following semantic versioning) when they're ready for testing.
Once a library version is tagged, we can use composer as part of our deployment to the testing environment. Following successful testing, we'd then deploy that same version to production.
The issue here, is that once we've tagged a version for testing, we have to be very careful as the newly tagged version will be picked up by composer when preparing the next prod release.
What I'm imagining, is that we'd tag a version as a beta or RC, (eg v1.1RC1) and somehow configure our deployment process such that it will refuse to deploy an RC or beta to production. If a version is tested successfully, we'd re-tag that version as a released version (v1.1RC1 -> v1.1) and release that.
Can this be achieved?
From what you are saying, I understand that you are actually afraid of tagging a new version of a library because that code could actually be used and break that other application, right?
One approach would be to do good testing. I don't see it should be a problem to tag a version of a library. If the tests are all green, there should be no reason not to tag it. This would work even if the tests are basically only "let's see if it works, manually".
Now the second step is to integrate that new version into the application: Run composer update and see if the application is still running, i.e. start all the tests and wait for green.
I guess it might be a good idea to have a separate area where you check out the application, intentionally run composer update to fetch all the newest libraries, run all the tests and report that a) there are updates and b) they work. A developer should then confirm the update, i.e. do it again manually and commit the resulting composer.lock file, or grab the resulting lock file from that update test.
I don't think there is benefit in using non-production release versions. You have to deal with the next version anyways - constantly toggling the minimum stability setting or adding #RC or #beta flags to the version requirements of the library don't really help.