github/meteor
1
1
Fork 0
mirror of https://github.com/meteor/meteor.git synced 2026-05-02 03:01:46 -04:00
Code Issues Packages Projects Releases Wiki Activity

Stop fiddling with local package build IDs

Browse Source 
We still prevent you from specifying a build ID in package.js, but we no
longer need it for internal rebuild-tracking purposes. (Maybe in the
future we can actually use it for tracking different builds of a
package?)
This commit is contained in:
David Glasser
2014-11-12 23:54:29 -08:00
parent 1dd0926d27
commit ccfd41ba7a
1 changed files with 1 additions and 50 deletions
Download Patch File Download Diff File Expand all files Collapse all files

51
tools/catalog-local.js
View File

@@ -149,11 +149,6 @@ _.extend(LocalCatalog.prototype, {
if (!_.has(self.packages, name))
return null;
var versionRecord = self.packages[name].versionRecord;
// The catalog doesn't understand buildID versions and doesn't know about
// them. Depending on when we build them, we can refer to local packages as
// 1.0.0+local or 1.0.0+[buildId]. Luckily, we know which packages are
// local, so just look those up by their local version instead.
version = self._changeBuildIdToLocal(version);
if (versionRecord.version !== version)
return null;
return versionRecord;
@@ -278,41 +273,6 @@ _.extend(LocalCatalog.prototype, {
if (_.has(self.packages, name))
return;
// Accurate version numbers are of supreme importance, because we use
// version numbers (of build-time dependencies such as the coffeescript
// plugin), together with source file hashes and the notion of a
// repeatable build, to decide when a package build is out of date and
// trigger a rebuild of the package.
//
// The package we have just loaded may declare its version to be 1.2.3,
// but that doesn't mean it's really the official version 1.2.3 of the
// package. It only gets that version number officially when it's
// published to the package server. So what we'd like to do here is give
// it a version number like '1.2.3+<buildid>', where <buildid> is a hash
// of everything that's necessary to repeat the build exactly: all of
// the package's source files, all of the package's build-time
// dependencies, and the version of the Meteor build tool used to build
// it.
//
// Unfortunately we can't actually compute such a buildid yet since it
// depends on knowing the build-time dependencies of the package, which
// requires that we run the constraint solver, which can only be done
// once we've populated the catalog, which is what we're trying to do
// right now.
//
// So we have a workaround. For local packages we will fake the version
// in the catalog by setting the buildid to 'local', as in
// '1.2.3+local'. This is enough for the constraint solver to run, but
// any code that actually relies on accurate versions (for example, code
// that checks if a build is up to date) needs to be careful to get the
// versions not from the catalog but from the actual built Isopack
// objects, which will have accurate versions (with precise buildids)
// even for local packages.
var version = packageSource.version;
if (version.indexOf('+') !== -1)
throw new Error("version already has a buildid?");
version = version + "+local";
self.packages[name] = {
packageSource: packageSource,
packageRecord: {
@@ -324,7 +284,7 @@ _.extend(LocalCatalog.prototype, {
_id: "VID" + self.nextVersionId++,
packageName: name,
testName: packageSource.testName,
version: version,
version: packageSource.version,
publishedBy: null,
description: packageSource.metadata.summary,
dependencies: packageSource.getDependencyMetadata(),
@@ -420,15 +380,6 @@ _.extend(LocalCatalog.prototype, {
if (! _.has(self.packages, name))
return null;
return self.packages[name].packageSource;
},
// Given a version string that may or may not have a build ID, convert it into
// the catalog's internal format for local versions -- [version
// number]+local. (for example, 1.0.0+local).
_changeBuildIdToLocal: function (version) {
if (version)
return version.split("+")[0] + "+local";
return version;
}
});