packager: attachHMRServer.js: fix callsite of Server#getModuleForPath()

Summary: In a previous changeset, Server#getModuleForPath() started returning `Promise<Module>` instead of `Module`, but the callsites in HMR haven't been updated, causing it to break. This would have been caught if `attachHMRServer.js` was using flow, that I'm considering doing in a following up diff. This would also have been caught if we had better integration testing of HMR. Good news however,it was caught by the OSS e2e test, that covers Hot Reloading.

Reviewed By: davidaurelio

Differential Revision: D4705937

fbshipit-source-id: fe787bc6ae50024759c7f7aeed747394fdce9aa1
This commit is contained in:
Jean Lauliac 2017-03-14 11:19:35 -07:00 committed by Facebook Github Bot
parent 0a7427f599
commit 4ac585b34b
1 changed files with 28 additions and 26 deletions

View File

@ -175,9 +175,9 @@ function attachHMRServer({httpServer, path, packagerServer}) {
entryFile: filename,
recursive: true,
}).then(response => {
const module = packagerServer.getModuleForPath(filename);
return response.copy({dependencies: [module]});
return packagerServer.getModuleForPath(filename).then(module => {
return response.copy({dependencies: [module]});
});
});
}
@ -195,32 +195,34 @@ function attachHMRServer({httpServer, path, packagerServer}) {
return {};
}
// build list of modules for which we'll send HMR updates
const modulesToUpdate = [packagerServer.getModuleForPath(filename)];
Object.keys(depsModulesCache).forEach(module => {
if (!client.dependenciesModulesCache[module]) {
modulesToUpdate.push(depsModulesCache[module]);
}
});
return packagerServer.getModuleForPath(filename).then(moduleToUpdate => {
// build list of modules for which we'll send HMR updates
const modulesToUpdate = [moduleToUpdate];
Object.keys(depsModulesCache).forEach(module => {
if (!client.dependenciesModulesCache[module]) {
modulesToUpdate.push(depsModulesCache[module]);
}
});
// Need to send modules to the client in an order it can
// process them: if a new dependency graph was uncovered
// because a new dependency was added, the file that was
// changed, which is the root of the dependency tree that
// will be sent, needs to be the last module that gets
// processed. Reversing the new modules makes sense
// because we get them through the resolver which returns
// a BFS ordered list.
modulesToUpdate.reverse();
// Need to send modules to the client in an order it can
// process them: if a new dependency graph was uncovered
// because a new dependency was added, the file that was
// changed, which is the root of the dependency tree that
// will be sent, needs to be the last module that gets
// processed. Reversing the new modules makes sense
// because we get them through the resolver which returns
// a BFS ordered list.
modulesToUpdate.reverse();
// invalidate caches
client.dependenciesCache = depsCache;
client.dependenciesModulesCache = depsModulesCache;
client.shallowDependencies = shallowDeps;
client.inverseDependenciesCache = inverseDepsCache;
// invalidate caches
client.dependenciesCache = depsCache;
client.dependenciesModulesCache = depsModulesCache;
client.shallowDependencies = shallowDeps;
client.inverseDependenciesCache = inverseDepsCache;
return resolutionResponse.copy({
dependencies: modulesToUpdate
return resolutionResponse.copy({
dependencies: modulesToUpdate
});
});
});
})