Support node-GYP

[paulmillr]

Hey there.

It would be great to be able to only install the NPM package without the brew stuff.

[sunshowers]

I don't fully understand this. Watchman is a C daemon that has multiple clients (Node, Python, Ruby...). There's a separate node package that allows easy talking to watchman. Are you asking for watchman itself to also be installed via node?

[wez]

You can npm install fb-watchman to get just the client today. The watchman service itself is a standalone daemon that can't be built into a node process as a module

[marcello3d]

It'd be nice npm install -g watchman to put watchman on your PATH without having to install brew (which I seem to remember screws up macports).

[stefanpenner]

installing a precompiled binary should be possible via npm (for specific platforms that support it) no need for gyp.

[wez]

We're not super keen on the idea of publicly distributing a binary.

Regarding macports, it looks like someone has contributed a watchman portfile: https://trac.macports.org/browser/trunk/dports/sysutils/watchman/Portfile I'll update our docs to add instructions for installing via macports

[wez]

https://trac.macports.org/ticket/47360 is tracking the missing pcre dependency for watchman on macports

[stefanpenner]

We're not super keen on the idea of publicly distributing a binary.

understandable, but it could make it entirely transparent for some users.

[wez]

I'd like to understand more about what the goal of this request is. What is the higher level problem that is perceived? Who does it affect? What do those people have to do today to resolve it?

Distributing binaries is a pain for a number of reasons, some around backwards compatibility, some around compatibility with other/existing distribution systems, some around tooling and infrastructure, some around security and integrity of the distributed binaries, all of which are multiplied by the number of supported operating systems.

Every supported OS has at least one high quality distribution system and we'd prefer to coordinate with the maintainers of those systems to ensure that watchman is made available in a well-supported manner.

[paulmillr]

What is the higher level problem that is perceived? Who does it affect?

It is unreasonable to expect users to install a) homebrew b) homebrew package c) node module instead of just a node module. It is bad for user experience.

The "distribution" may be painful for you, but please don't forget about end-users. It is a real pain for them to execute more and more unneeded commands, be it CEO trying to follow consultant's instructions, a clerk trying to install an actual mac app that depends on watchman or anyone else. It's just 3x more stuff that can go wrong.

We'd like to include watchman as a dependency for popular nodejs file watcher, chokidar. Think of 1.17M installations from the past month that could have included watchman. I can't even think of all the current use-cases for the software — user-friendliness plays very important role right here.

[wez]

There's no hard dependency on watchman in that scenario. I'm asking about how this results in a broken experience?

Watchman is a service with multiple clients. The vast majority (perhaps all?) of other similar software services that have node clients is not deployed via npm. The clients are, but not the server component.

It seems to me that chokidar already has a great out-of-the-box experience. Adding watchman support is possible and easy to do in such a way that it won't spoil this experience; the fb-watchman package has no hard dependency on the server component and can detect its presence (or not) at runtime.

If there are issues that make this difficult or frustrating then we'd be happy to make this aspect more smooth.

[paulmillr]

I'm asking about how this results in a broken experience?

Watchman seems to be more reliable than other solutions. Using it instead of other solutions brings better experience to the board. So, it is kinda broken when we get rid of it.

[stefanpenner]

So, it is kinda broken when we get rid of it.

:+1:

@wez I think what you are feeling is, "why whats wrong with <insert package manager here> way of installing watchman?"

Well, tooling authors would prefer to just have watchman available by default. Why? The alternatives are more or less broken experiences for our users and saying, please install tool Y to magically improve tool Z, kinda blows.

Our goals are to mitigate our users pain points and that mostly means figuring out ways to ship with batteries included.

I also appreciate your point of view, I wonder if we can figure out some solution that appeals to most.

For reference ember-cli, does the following:

• if not OS X or Linux, just use NodeWatcher
• if a watchman we don't recognize is installed (there is a node_module named watchman), display a warning
• if watchman is not installed, display a message that suggests users install it
• if watchman is the right version, prefer it to the alternatives

the detection codez: https://github.com/ember-cli/ember-cli/blob/master/lib/models/watcher.js#L79-L126

The above is tolerable, but it still causes confusion for our users. Maybe you have some ideas on how to reduce that confusion?

[amasad]

It's worth noting that the daemon model of watchman is a big part of what makes watchman great. It might make the onboarding user experience a bit better as a node extension but as a daemon you get instant results when querying the watched source tree, and with the watch-project command we can consolidate multiple watches if they overlap which makes it perform better.

If watchman can solve this reliably for every platform (I hear windows support is in the works). Then all developers should have it installed so we can get this thing behind us already and get on with our work. If your project introduces your developers to watchman they'll install it once and any other tool can benefit from the same install. For example, if you used react-native, you should be able to use webpack with the same watchman install.

[es128]

@amasad agree with your points, but it would still be nice if there was a way to get it seamlessly installed via npm. If it can be done with a shell script, without external dependencies like homebrew, then this could probably be accomplished.

Previously installed watchman could be detected to make the script exit as noop on subsequent npm installs, or perhaps even handle semver-style updates.

[wez]

Literally doing something with node-gyp isn't on our roadmap, so I'm closing this issue. It sounds like you're really asking for watchman to be more ubiquitous and easy to install on a variety of operating systems. I'd like to track each one of those systems/distributions as its own issue, but also want to give fair warning that our stance on this is that we'd like someone to volunteer and commit to act as the maintainer for each one, as we simply don't have bandwidth to give this the attention it deserves ourselves.