Warning against sourcing Infusion from git-based package references

Tony Atkins tony at raisingthefloor.org
Fri Jan 6 12:45:59 UTC 2017


Hi, All:

I just wanted to point out that this is not at all unique to fluid.  Any
repo/hash whose version in the package.json file matches a released version
will suffer from this problem.  I have had the same problem with kettle,
and with my own gpii-x contrib packages, which also use the last released
version in the repo's package.json.

This adds volume to the call to start regularly using fluid-publish to
create dev releases.   In addition to avoiding this problem, It's much
clearer to interpret than repo/hash references.  I used to keep a detailed
dependency diagram when pushing multiple repo/hash references through to
downstream projects, now I can just use "npm outdated" or "yarn outdated",
which is a huge time saver.

Cheers,


Tony

On Thu, Jan 5, 2017 at 9:00 PM, Antranig Basman <
antranig.basman at colorado.edu> wrote:

> Just before Christmas, Tony Adtkins and I ran into a very unfortunate
> cache corruption issue which seems to affect both yarn and npm, in the case
> where you are working with multiple versions of Infusion (or indeed, one
> imagines, any project) throughout a tree which at some sites is sourced via
> npm module references and at other sites is sourced via git URLs. It
> appears that our habit of storing the version number of a real released
> package within the package.json held within git (at any time) raises the
> possibility of the package manager's cache of the package contents becoming
> corrupt - including in a way not related directly to the version or package
> which is conflicting. This is written up at https://issues.gpii.net/browse
> /GPII-2179 and some commentary is on a pull request for infusion-docs
> where the issue was first encountered:
> https://github.com/fluid-project/infusion-docs/pull/103#
> discussion_r92831132
>
> What we observed was that npm was capable of installing a version of
> Infusion *whose contents mismatched its package version* - in fact, were
> those of an unrelated and old version of Infusion which had been referenced
> via a git URL, a broken version which suffered from the problem described
> at https://github.com/fluid-project/infusion/pull/577#issuecomm
> ent-255065212 - this was referenced by some nested project, and the
> contents of this Infusion ended up displacing those in npm's cache when it
> resolved the top-level Infusion reference which was to a more recent, fixed
> version. In this case therefore Infusion's "self-deduping" algorithm was
> useless since the contents of the highest resolvable Infusion in the
> installed module tree were corrupt. Adtkins has confirmed that yarn is
> capable of generating this problem as well.
>
> The take-home, executive summary is - do not reference Infusion via git
> repository references in package.json. If there is an urgent fix that you
> need, please ask a core team member to roll you a dev release which can be
> referenced via the npm registry - this is very quick and easy for them to
> do via the fluid-publish module.
>
> Cheers,
>
> Antranig
> _______________________________________________________
> fluid-work mailing list - fluid-work at lists.idrc.ocad.ca
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20170106/ebbcc11c/attachment.html>


More information about the fluid-work mailing list