[1.4.2] Changes in npm linked modules no longer cause a rebuild

[damonmaria]

My guess is in improving build speed this functionality may have been dropped intentionally, but maybe it's an oversight.

In 1.4.1 if I updated any of the several npm packages I am working on that are npm linked to the node_modules of the Meteor project then Meteor would rebuild. This no longer happens in 1.4.2.

Is this the way it's supposed to be?

MacOS 10.12.1

[benjamn]

Yes, starting watchers for files in node_modules was prohibitively expensive, so now (in Meteor 1.4.2) we watch for changes only in the contents of node_modules directories. I'd be happy to consider further refinements, but it can't involve watching everything in node_modules.

[damonmaria]

Totally understand. And I'm willing to lose linked modules causing a rebuild for faster build speed.

But I wonder if a child of node_modules is a symlink (should be a good determinant of npm lnked) then it could be 'deep watched'? We've moved a lot of our common Meteor code out to npm modules and a lot of our editing goes on in those rather than the project we're working on.

I just tried to see if I could workaround this manually and trigger a rebuild by touching the symlink but that didn't work. But then I tried it on an ordinary directory in node_modules (react) and that didn't trigger a rebuild either. So maybe fsnotify or whatever it is doesn't see that as a change.

Another possibility is to expose in Meteor shell a way to invalidate a path so we can trigger a rebuild if we want.

Also, just to complicate things, all our packages are npm scoped packages and so the actual package dir is not directly under node_modules. Just mentioning that in case it affects anything.

[jchristman]

I second the idea of 'deep watching' symlinks in node_modules. The only way that anything should be linked is if someone is intending on editing that module without having to reinstall or update every time they make a change. I think that is likely the simplest solution.

[hexsprite]

the only problem with deep watching symlinks is that they often have their own node_modules inside them... so maybe that could be excluded.

[benjamn]

Yep, I think this would only apply to symlinks in the top-level node_modules directory in the app, right?

[jchristman]

Tldr; watch all symlinks and their subsequent symlinks in their node_modules, but don't watch the normal node_modules of the symlinked things.

Well - there is theoretically the use case where A is symlinked to B, which is symlinked to project C, yes? In my specific use case, I only have devDependencies in the node_modules of the thing that is symlinked, because when I get around to publishing it, the dependencies will be installed. But I do believe it is in fact possible to have a linked module depend on another linked module. So maybe watch all symlinks to an arbitrary depth, but don't watch anything else? I understand the performance hit here, but the ability to have this use case may prove useful to someone?

[benjamn]

This should be fixed if you run meteor update --release 1.4.2.1-beta.0 in your app directory.

[jchristman]

Awesome I'm loving the quick release cycle with the betas. You guys rock!

[damonmaria]

Just one thing. We use @Scoped packages. So the symlinks to our package are 2 levels deep.

e.g. node_modules/@mindhive/components where components is the symlink.

That's for the super quick update. Wow.

[damonmaria]

FYI I'm not getting any rebuilds from updating my npm linked packages using beta 0. Not sure if it's because they're scoped packages like mentioned above, or another reason.

[benjamn]

When you get a moment, please confirm whether this is fixed (especially for @Scoped packages) by meteor update --release 1.4.2.1-beta.1. Closing now because it seems to be fixed in my tests, but of course feel free to reopen if you discover otherwise!

[damonmaria]

I can confirm (for me) that Meteor 1.4.2.1-beta-1 rebuilds with updates to @Scoped linked packages. And rebuilds pretty damn quick I might add.

Thanks for the quick fix @benjamn. Mighty impressed.

[benjamn]

Sweet!

[mjgallag]

@benjamn With 1.4.2.1-rc.0, if I delete index.js it triggers a rebuild, but when I recreate index.js it doesn't trigger a rebuild.

[mjgallag]

@benjamn with 1.4.2.1 an update to the main js file triggers a rebuild. Updates to js files imported by the main js file don't trigger rebuilds. Let me know if I should open a new issue. Thanks for your help.

[mjgallag]

@benjamn with 1.4.2.2-rc.1 I no longer have to touch my main js file to trigger a rebuild, thank you for the quick fix!

[benjamn]

Good to know that e4c7b08 did the trick!