Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
pbjs, pbts dependencies #618
protobuf.js version: 6.4.0
run pbjs and not have it lazily load dependencies
i.e. it takes two runs of the
The problem is caused by the fact that the dependencies required for the provided binaries are declared as
However, pbjs and pbts are tools that are meant to be used as devDependencies in projects that are using protobufjs.
I see that protobufjs has a small dependency set, and that's a good thing; thus we cannot just move
Would it make sense to put these scripts in a separate package, exposing its dependencies as
I'm I missing something?
I did this because I noticed that some people forked protobuf.js v5 in order to remove the pbjs dependencies from the package. So I thought that making them install on demand once by looking them up from devDependencies would be a good thing.
In my tests, this mechanism worked fine. Must have missed something there.
added a commit
Jan 4, 2017
added a commit
Jan 5, 2017
I was just bitten by this bug when including protobufjs within a lerna-powered project. A package had pbjs as a prepublish step, which of course failed the first time. It's bizarre to run the exact same command a second time and have it work. In addition, this behavior assumes
If the dependencies of pbjs are too heavy then perhaps pbjs should be a separate package? I'm not sure the dependency weight is actually a concern here compared to breaking developer assumptions.
Latest released is 6.6.3, last 6.4.X was 6.4.6 (see).
Actually, cli utilities assume that node is installed, which uses
The current setup is there because both library and cli are tightly coupled, and because the npm package contains all the common things anyway. Dependency weight hasn't been an issue to me in the first place, I just noticed that others felt the need to fork protobuf.js without the cli.
Hence, it's merely a compromise (no additional package to manage, no extra work for me, yet a super small dependency footprint), but it should be working properly as of today. If it isn't with latest, let me know, and I'll reconsider splitting it up.
We ran into this issue today. We were initially running on version 6.4.5, but reproduced the issue on both 6.4.6 and 6.6.4.
Our current solution is to add a postinstall script to run pbjs and throw away the output, so that future invocations will work, but we'd prefer to get rid of this additional step if we can.
We invoke pbjs with the following command as part of our compilation script:
Running on OS X 10.11.6, node 7.1.0, npm 3.10.9, bash 3.2.57
Here's the output of the first and second call:
Error: Cannot find module 'espree'