Just to tell that i tried the build with the current version of devel and it works fine ! Thanks

We have a different architecture and we build our code inside the packages.

We've been depending on the client folders within packages to speed things up, but after this merge I don't think this would be feasible. I think the consistency of the dev experience inside/outside the packages was a valid assumption.

I've been trying to understand from the issue which prompted this patch: is removing this special treatment of client and server the only possibility of fixing it? If Meteor really wants to drop the packages completely, then this move would be understandable. Otherwise, it precludes one of the really great features of Meteor, the possibility of developing truly modular applications, in the vein of Vulcan for instance.

It is a real shame that we don't have this anymore, as it makes it more difficult to develop large yet pluggable applications.

Can you explain more clearly the technical consequences of this? What happens when I import my-package server-side for example, and client-side? As-is, this update is worrying for application relying massively on Meteor isomorphism and package system, Vulcan is a good example.

Edit: I think this thread answers my question: https://forums.meteor.com/t/meteor-1-8-1-client-and-server-directories-in-packages/48452/3

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!

Thank you for checking this up, @benjamn. We are already using the where argument, exactly as you describe (actually, since Meteor 1.3, so we never had to rely on the 'special treatment' ever again). But the problem with the full rebuild when client files are changed is still there nonetheless, and it can be quickly replicated as described in #10449.

It seems like this is an older, hidden bug, as described there:

(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)

@manueltimita Right, what you're doing should be enough to make this work without any code changes on your side. However, there are some flaws in the way Meteor currently determines whether it's safe to do a client-only refresh (namely, it relies on client/ directories, not the actual dependency graph). Fixing those flaws would be beneficial for everyone who uses Meteor. I've updated my previous comment to make this somewhat clearer.

Thank you for the clarification, @benjamin.

I'm confused. I'm currently on Meteor 1.8 and have the "special" directories server/client/both. This to me makes sense and I don't know why anyone would want to change that.

What I don't like is the imports directory. I think things should act like they do today inside the imports directory, where server/client/both mean what they say, but without the imports directory.

Are we still going to have special directories server/client/both in the future?

@aadamsx We're talking about packages here, not application code. We're going to keep the client/ and server/ directories for application code for the foreseeable future, though we might be able to do a better job detecting client-only refreshes using the dependency graph, which would effectively render the client/ directory unimportant.

If you would like all your application code to be loaded lazily by default, so you don't have to worry as much about the imports/ directory, you can use the meteor.mainModule configuration option in package.json that was introduced in Meteor 1.7:

• Applications may now specify client and server entry point modules in a
  newly-supported "meteor" section of package.json:

  "meteor": {
    "mainModule": {
      "client": "client/main.js",
      "server": "server/main.js"
    }
  }

  When specified, these entry points override Meteor's default module
  loading semantics, rendering imports directories unnecessary. If
  mainModule is left unspecified for either client or server, the
  default rules will apply for that architecture, as before. To disable
  eager loading of modules on a given architecture, simply provide a
  mainModule value of false:

  "meteor": {
    "mainModule": {
      "client": false,
      "server": "server/main.js"
    }
  }

  Feature #135
  PR #9690