Implements feature request #406 by allowing to type a --json option
and let the tree output be in JSON format. The entries consist of
the package name as key and either String value (version number +
top-level or expanded-above) or an Object with the following
properties:
- version (String) - always
- local (Boolean) - only if true when package is built from source
- weak (Boolean) - only if true
- newerVersion (String) - only if exists
- dependencies (Object) - only if > 0 and not all weak
In order to also support a more detailed output, there is a --details
option. If it's active, the following properties are added, too:
- earliestCompatibleVersion (String) - always
- debugOnly (Boolean) - only if true
- prodOnly (Boolean) - only if true
- testOnly (Boolean) - only if true
- containsPlugins (Boolean) - only if true
- lastUpdated (Date-String) - always
- published (Date-String) - always
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.
