You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I'd originally filed this as hayes/unpm#83, but @hayes informed me this is probably a better place for it.
I'm hazy on the exact details, but it sounds like the problem is that some part of npm will sometimes add metadata for releases of packages, metadata that's not in the package.json file, which clone-packages ignores. It seems that npm used to not care, figuring it out from the package itself either way, but modern npm (3 or 4) seems to rely on the server for this information. The issue for me is that packages cloned into my unpm instance are missing scripts.install even if they need building, where scripts.install is present on the public registry (even though it was never in any package.json), so depending on what registry I install the package from and which version of npm I'm using, npm install may or may not give a usable package.
Again, please see hayes/unpm#83 for the full context here, and @hayes' ideas for how to fix. I'm afraid I don't know enough details to be much more help with specifics, but I'm happy to try to answer any questions or run any experiments. Thanks!
The text was updated successfully, but these errors were encountered:
Hi, I'd originally filed this as hayes/unpm#83, but @hayes informed me this is probably a better place for it.
I'm hazy on the exact details, but it sounds like the problem is that some part of npm will sometimes add metadata for releases of packages, metadata that's not in the package.json file, which clone-packages ignores. It seems that npm used to not care, figuring it out from the package itself either way, but modern npm (3 or 4) seems to rely on the server for this information. The issue for me is that packages cloned into my unpm instance are missing scripts.install even if they need building, where scripts.install is present on the public registry (even though it was never in any package.json), so depending on what registry I install the package from and which version of npm I'm using, npm install may or may not give a usable package.
Again, please see hayes/unpm#83 for the full context here, and @hayes' ideas for how to fix. I'm afraid I don't know enough details to be much more help with specifics, but I'm happy to try to answer any questions or run any experiments. Thanks!
The text was updated successfully, but these errors were encountered: