We haven't always updated this minimum version when we've changed the
Node.js version bundled with Meteor, which is fine because most deployment
strategies (including Galaxy) use the right version of Node.js
automatically. With Meteor 1.9 and Node.js 12.14.0, however, it seems
important that we make absolutely sure new Meteor apps are not getting run
in production with an end-of-life'd version of Node.js (v8).
https://github.com/meteor/meteor/pull/10772#issuecomment-553517459
The assertion in tools/fs/optimistic.ts was failing if I passed a relative
path for --test-app-path, and passing the path as a second argument when
calling assert made it easier to tell what was going on, so I decided to
keep that change.
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.
Sometimes, before dev_bundle/bin/.meteor-commands.json has been written, a
command like `./meteor npx tsc` can fail because `npx` is not blessed in
the same way `node` and `npm` are. Since `npx` is a core tool that we want
folks to be able to use without confusion, I think it makes sense to
include it in the list of known subcommands.
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)
In my local development environment, the `meteor` command resolves to my
Meteor checkout, and I use `~/.meteor/meteor` explicitly when I want to run
a released version of Meteor.
If I run
~/.meteor/meteor npm test
and the `package.json` file defines an npm `test` script that refers to
`meteor`, in my environment this `meteor` won't be the same as the one I
used to run `~/.meteor/meteor npm test`, which can introduce weirdness
such as pinning the versions of packages in `meteor/packages/non-core`,
and all the usual Meteor version inconsistency risks.
This commit fixes that problem by prepending the directory that contains
the `meteor` (or `meteor.bat`) executable to the `PATH` before running
`meteor npm ...` commands.
This is a follow-up to b4a68e99c1, which
allowed obtaining a simplified list of build architectures (without
web.browser.legacy) by calling isopack.buildArchitectures(true), which was
helpful for matching existing builds of packages that were published
before the web.browser.legacy architecture was introduced in Meteor 1.7.
Now that some packages have been published with the web.browser.legacy
architecture as part of the Meteor 1.7 release, it's important to try
matching the full unsimplified list of architectures, while still falling
back to the simplified list for other packages.
Before this change,
meteor create --list
would produce output containing the following line:
todos-react: https://github.com/meteor/todos#react
but "meteor create --example todos-react" would create the blaze version of the todos example.
This was because for some reason the code is using a # to append the name of the branch, instead of /tree/.
