SQLite has a worse-is-better philosophy about automatically converting
between different data types, such as strings and floating point numbers:
https://www.sqlite.org/quirks.html#flexible_typing
This means querying for the string "1.10" in a given column can return
rows where the column is actually the string "1.1", since SQLite imagines
you might be talking about the number 1.1, rather than the string you
actually requested.
This "feature" became a problem for Meteor after we published Meteor 1.10,
which caused SQLite to return multiple rows for the getReleaseVersion
query, including both Meteor 1.10 and Meteor 1.1 (which is ancient, from
March 2015).
While this behavior seems completely indefensible, the SQLite
documentation clearly does not consider it a bug, which forces us to work
around the consequences by double-checking the queried results with the
filterExactRows helper function.
Unfortunately, this conversion triggered an error due to one of the
shortcomings of the Babel implementation of TypeScript:
SyntaxError: /tools/tool-env/profile.ts: Namespace not marked type-only declare. Non-declarative namespaces are only supported experimentally in Babel. To enable and review caveats see: https://babeljs.io/docs/en/babel-plugin-transform-typescript
278 | }
279 |
> 280 | export namespace Profile {
| ^
281 | export let enabled = !! process.env.METEOR_PROFILE;
282 |
283 | export function time<TResult>(bucket: string, f: () => TResult) {
at File.buildCodeFrameError (/Users/ben/meteor/dev_bundle/lib/node_modules/@babel/core/lib/transformation/file/file.js:261:12)
at transpileNamespace (/Users/ben/meteor/dev_bundle/lib/node_modules/@babel/plugin-transform-typescript/lib/namespace.js:25:25)
at PluginPass.TSModuleDeclaration (/Users/ben/meteor/dev_bundle/lib/node_modules/@babel/plugin-transform-typescript/lib/index.js:271:32)
at newFn (/Users/ben/meteor/dev_bundle/lib/node_modules/@babel/traverse/lib/visitors.js:193:21)
at NodePath._call (/Users/ben/meteor/dev_bundle/lib/node_modules/@babel/traverse/lib/path/context.js:53:20)
at NodePath.call (/Users/ben/meteor/dev_bundle/lib/node_modules/@babel/traverse/lib/path/context.js:40:17)
at NodePath.visit (/Users/ben/meteor/dev_bundle/lib/node_modules/@babel/traverse/lib/path/context.js:88:12)
at TraversalContext.visitQueue (/Users/ben/meteor/dev_bundle/lib/node_modules/@babel/traverse/lib/context.js:118:16)
at TraversalContext.visitMultiple (/Users/ben/meteor/dev_bundle/lib/node_modules/@babel/traverse/lib/context.js:85:17)
at TraversalContext.visit (/Users/ben/meteor/dev_bundle/lib/node_modules/@babel/traverse/lib/context.js:144:19)
Once Windows developers update to a 64-bit version of Meteor 1.6, they may
still wish to run apps using older versions of Meteor where only 32-bit
builds of meteor-tool are available. This commit makes that possible.
These changes introduce dual Mongo support into the Meteor
Tool. 32-bit Mongo (3.2.15) will be used by Meteor when the
Tool is run on a 32-bit OS (32-bit Linux and Windows). 64-bit
Mongo (3.4.9) will be used when the Tool is run on a 64-bit
OS (64-bit Linux, Windows and macOS).
Fixes https://github.com/meteor/meteor-feature-requests/issues/129.
This is a refactor/finishing-move of @c9s's original PR meteor/meteor#7586.
This maintains backward compatibility with PACKAGE_DIRS using the original separator that it expected (':'). Users of the new METEOR_PACKAGE_DIRS variable should use the correct path separator for their platform (`:` on BSD/Linux and `;` on Windows).
Fixesmeteor/meteor#7585Fixesmeteor/meteor#4204
Recording process.versions allows us to be much more aggressive about
rebuilding binary dependencies whenever the version of Node/V8 might have
changed, even if the package was not just downloaded.
When we call readAndWatchFileWithHash, if the file does not exist, we
still want to add it to the watchSet with a null hash. Later, however, we
have to be careful we do not assume every file in watchSet.files exists.
- We don't want to do a bunch of parsing *per comparison* when sorting
a list of package version strings. package-version-parser's `compare`
(and server's `compare`, which it uses) both accept either a string
or a parsed record. By parsing explicitly with memoization, we avoid
a super-linear blow-up in the amount of parsing. This'll save someone
half a second, at least.
- Adjust profiling hooks and messages
- Expose `Profile` to isopackets
It's very useful to be able to include code only in production. It's
useful for React integration, but presumably also for many apps.
* Add prodOnly boolean flag alongside debugOnly in Package.describe
* Packages the set prodOnly to true auto-depend on isobuild:prod-only
(making them error in the old tool where prodOnly isn't supported)
* The `includeDebug` boolean build option is replaced by a string
named buildMode, which can be 'development' or 'production', just
like minifyMode.
Tested by self-test.
