Open kud opened 10 years ago
Yes it is not compatible. It could be a bit more friendly if #18 is implemented but not sure if it would completely fix it.
As first step, couldn't we just make napa ignored from npm-shrinkwrap
?
How would we do that?
I have no bloody idea lol :)
I should have a look. It's quite interesting. ;)
got bit by this too, shrinkwrap is a requirement at the current stage / size of the project I cannot afford to not have it...
Looking for a workaround, any suggestions would be greatly appreciated.
So since we have a no-go from NPM i guess the next sensible solution would be to have our own conf file napa.json
... I'm down with that... @shama any other play here?
(sorry for pressing, this is a pain in my production installs)
napa.json would be the answer in my opinion.
I'm looking into a way to get it to play nice with shrinkwrap. Hopefully we can get away with just adding a command napa shrinkwrap
. I really don't want to create our own config file as that would make napa an official: yet another package manager™
You're right about another package manager.
Yes indeed, even if we create a napa.json
file that won't stop shrinkwrap from breaking as it'll find napa's extraneous packages in node_modules
Does the solution to #22 also have an effect on this?
If so, I think updating that key with the package names becomes a pretty important feature.
@bjmiller Unfortunately it doesn't help with this issue as packages are reported extraneous even when put into bundledDependencies
.
I just ran into this myself. Any chance that a fix has been implemented or a workaround discovered?
Soooooo... @shama what's the plan?
The bad part? It pretty much changes the way napa works entirely. The good part? It also solves #22, and will make #31 trivial to implement.
So, here's how it goes...
napa_modules
npm --save-optional file:napa_modules/module-name
Saving it to optionalDependencies
makes npm shrinkwrap
and npm prune
look the other way. Also, since repos aren't in node_modules
, we don't have to delete the .git
subdir anymore (ref #53), so as far as versioning goes, we can just run a git checkout REV
, assuming HEAD
if not supplied, in each napa_modules
repo each time napa
is ran. Thus ensuring the versions in package.json
stay in sync w/ installed napa packages, and that when unspecified, the latest version will always be used.
UPDATE: Turns out, we wouldn't have to separate them into a napa_modules
dir at all. We just have to add the package to optionalDependencies
and ensure that the version numbers match.
i.e. clone into node_modules/module-name
, create the package.json, and add "module-name": "1.0.0"
to package.json
-> optionalDependencies
This method fixes #22 as well.
Also, the decision to use optionalDependencies
vs dependencies
is agnostic of which of those approaches is taken and is based on the fact that if we modified the dependencies
field and that was then committed, npm would try to install a package that doesn't exist yet.
Any news on this particular issue?
upgrade to node 4.x+ and you won't be needing napa any more
I am trying to implement shrinkwrap. Can someone help me understand what thanpolas is talking about. I tried googling for what he is talking about but his comment did not provide enough information to be useful. I would appreciate it. Thanks!
I can't say what @thanpolas meant, but I can give a pessimistic word of warning. I had made pretty decent progress getting npm shrinkwrap
to work, only to have an upgrade to npm stop me in my tracks; I've since abandoned it.
How are you going about implementing it?
since i assume that a napa dependency is inherently more volatile than an npm dependency, i didn't bother trying to get napa to play nice with npm shrinkwrap. Instead i added support for a "directory" option in napa-config. Since I can now house my napa dependencies external to node_modules (napa_modules), I'm able to shrinkwrap npm dependencies.
You can see the feature in my fork which needs tests written, so i haven't done a pull request.
Good thinking. When used with webpack you could add napa_modules
to resolve.modulesDirectories to require as if it lived in node_modules
. I'm sure a similar option exists for Browserify and the like.
@linkabi9 with node 4+ and onwards you can directly link github repos using npm thus rendering napa obsolete.
@thanpolas You could do that before I believe; the issue comes into play when there is no package.json. Unless I'm mistaken.
@thanpolas Are you referring to npm's ability to reference github repos in the shorthand (linkabi9/napa for example)? If so, the solution does not fulfill my requirements. napa allows me to include dependencies that are source controlled when they don't have a package.json. can you provide content?
*edit: just saw we said the same thing @caseyWebb
@caseyWebb i did the same thing to my webpack config. nice to know others think along the same lines. also happy that webpack supported this unique requirement with minimal effort.