[1.8.1-beta.16] #10414 results in server rebuilds on client code changes in packages

[larswolter]

#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
cd test
meteor create --package custom
meteor add custom

change packages/custom/package.js to load different mainModules

  ...
  api.mainModule('client/client.js', 'client');
  api.mainModule('server.js', 'server');
  ...

create files packages/custom/client/client.js

  import '../custom';
  
  console.log('Hello Client!');

and packages/custom/server.js

  import './custom';
  
  console.log('Hello Server!');

now changing packages/custom/client/client.js results in client rebuild only

Now update

meteor update --release 1.8.1-beta.16

now changing packages/custom/client/client.js results in server rebuild

(As a side note, also in 1.8.0.2 a server rebuild is done, when client js is located in packages/custom/client.js so the original problem is much older i suppose)

[aogaili]

This is not good, serious regress since we depend on placing files in client folder during development within packages.

[manueltimita]

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.

[aogaili]

We've the same architecture and I'm really hoping we can get the old behaviour back.

[aogaili]

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.

I think benjamin has the the right solution in mind:

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?

[benjamn]

Fixed in recent 1.8.2 betas/RCs by #10686.