This fixes the bug where commands like `meteor add-platform ios` would
fail the first time with an error that cordova-lib could not be found,
even though we attempt to install the necessary packages if they have not
already been installed.
To make a very long story short, calling moduleDoesResolve before
installing dependencies like cordova-lib was causing Node.js to cache the
_absence_ of cordova-lib/package.json permanently in the new
packageJsonCache, which cannot be invalidated or cleared by user code:
f8f20892e9/lib/internal/modules/cjs/loader.js (L245-L255)
Although we could potentially propose a change to Node to allow the
packageJsonCache to be invalidated, a more immediate solution is simply to
avoid calling moduleDoesResolve when there's any chance the module will
not resolve. Because we still want to avoid repeatedly installing Cordova
dependencies every time we run a Cordova command, we instead check whether
the necessary dependencies are installed by examining the file system.
Revert "Bump webapp version to 1.8.2, with same content as 1.8.0."
This reverts commit 20d2a9b4a4.
Revert "Revert changes to webapp package since version 1.8.0."
This reverts commit 7a6ee9e129.
We accidentally published changes to webapp that should have been
restricted to Meteor 1.10 as part of the 1.8.1 version. This commit
reverts commits to packages/webapp since Meteor 1.9, so that we can
republish the 1.8.0 content as version 1.8.2. We will then bump the webapp
version to 1.9.0 on the release-1.10 branch and publish the new content
only on that branch.
Revert "Allow to exclude web architectures in development mode (#10824)"
This reverts commit a205967186.
Revert "Updates cordova-plugin-meteor-webapp to 1.7.1"
This reverts commit a1e4d27822.
Revert "Update cordova-plugin-wkwebview-engine to 1.2.1."
This reverts commit 3f9a69d7c4.
Revert "Update cordova-plugin-whitelist to 1.3.4."
This reverts commit 979273333b.
Revert "Update cordova-plugin-meteor-webapp to 1.7.1-beta.1."
This reverts commit 565c4254f1.
Revert "Update accounts-password to version 1.5.2."
This reverts commit b827d1da2f.
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.
