#10414 in the current 1.8.1 beta results in client/server directories not treated special anymore.
We structured our packages with client and server directories and changing a file in a client directory triggers a client rebuild only.
After #10414 the server gets also rebuild.
A small reproduction:
meteor create --full test
meteor create --package custom
meteor add custom
change packages/custom/package.js to load different mainModules
In our case, also, the packages are essential. We use them to split the application 'vertically', with client and server code for an entire application section residing inside the same package. It's a very neat architecture that can hardly be achieved using only ES6 modules. It allows decoupling the application in independent parts, which can be plugged / unplugged by just adding / removing a package.
Please bring the old behaviour back. The current state of facts makes life really tough when working with 70 - 80 local packages.
This regress has severely impacted our development workflow, any client side change (within packages) will require full server rebuild, basically any change within the package will result in full server restart.
Anyone who is using package based architecture (such as VulcanJS) will be impacted. And any new comers who will not use client folders or developing client side files within packages will also be impacted.
The regress was a side effect of ignoring client/server folders within packages which resulted in the client watchSets being impacted. Given that Meteor isomorphic package system is one of its biggest advantages, I think resolving this should really be prioritized.
The right way to fix this will be for Meteor to respect the "where" argument to api.addFiles(..., "client") and api.mainModule(..., "server") in package.js when deciding whether a file change is client-only or requires a server restart. Using client/ and server/ directories in packages was an accident that caused bugs like #10393.
Note: the current implementation of client refreshing needs to be improved to use the "where" argument correctly, so this comment is a statement of intention, not immediately useful advice. Sorry for the inconvenience, in the meantime!
Hopefully this get resolved soon, I tried to look into it but it's not clear to me how Meteor sorts the server/client files when building the packages.
Meanwhile, what workarounds are you guys using if any?
Most importantly, this change means that changes to files not used by the
server bundle will not trigger a server restart.
Fixes#10449 by implementing the strategy I described in this comment: