Although the Meteor jquery package is no long a core package (and thus is
not tied to the Meteor release), it seems like a good idea to nudge folks
towards installing jquery from npm, instead of relying on the very old
version (1.12.1) residing in meteor/packages/non-core/jquery/jquery.js.
Closes#10289.
This is important so that tools like VSCode will pick up the correct
version of the TypeScript SDK, rather than whatever default version was
installed with VSCode.
Just as developers can run
meteor create --react my-react-app
meteor create --minimal my-minimal-app
meteor create --bare my-bare-app
meteor create --full my-full-app
they can now run
meteor create --typescript my-typescript-app
to produce a new TypeScript application, based on the --react application,
configured using a recommended tsconfig.json file.
This app represents the current best/simplest-known way to set up a
Meteor-compatible TypeScript application, but it is still very much a work
in progress. Please feel free to submit pull requests to improve it, or
create issues to discuss how it should work.
For example, the community-maintained @types/meteor package covers all the
core packages used by this starter application, but it has not been
updated in a while, so there will no doubt be meteor/* packages with
missing types. In future versions, Meteor should ideally generate the
appropriate .d.ts files from TypeScript package source code, so that no
separate @types/meteor/* declarations need to be maintained.
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)
This saves us from having to install @babel/parser in the server bundle.
There is currently a bug in Reify that prevents it from loading this
parser by default, but we can work around that on the Meteor side for now.
This information is useful when you need a unique identifier for the
current version of the application (and you're using Git).
If the current Git HEAD revision can't be found for any reason, the
gitRevision property simply will not appear in star.json or
__meteor_runtime_config__.
Probably the most notable change in this update is that the Reify compiler
now generates
module.link("./child", { ...setters... });
instead of
module.watch(require("./child"), { ...setters... });
for import and export-from declarations.
This only affects newly created applications for now, but developers can
update to the latest meteor-node-stubs by running
meteor npm install meteor-node-stubs@latest
https://github.com/meteor/node-stubs/issues/15
All Meteor packages implicitly depend on the meteor package, and the
meteor-base package implies the meteor package for most Meteor apps, but
the new minimal skeleton does not use meteor-base, so minimal Meteor apps
were not directly depending on the meteor package.
The only reason this mattered was that the meteor package registers a
default compiler plugin for CSS files, and compiler plugins only apply if
an app or package directly depends on them (or depends on a package that
implies them, such as meteor-base).
In other words, this change reenables support for raw CSS files for
minimal apps.
