Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

larswolter opened this issue Feb 13, 2019 · 4 comments


Copy link

commented Feb 13, 2019

#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 a server rebuild is done, when client js is located in packages/custom/client.js so the original problem is much older i suppose)


This comment has been minimized.

Copy link

commented Feb 20, 2019

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


This comment has been minimized.

Copy link

commented Apr 4, 2019

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 comment has been minimized.

Copy link

commented Apr 4, 2019

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


This comment has been minimized.

Copy link

commented Jul 12, 2019

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.