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.
This function determines whether the optimistic caching system should
subscribe to file change notifications for a given path.
Note that Meteor has other ways of watching for file changes (e.g. the
WatchSet abstraction), as well as other mechanisms for invalidating cached
results, so time and resources can often be saved by returning false here,
if we know that the path will be watched in other ways.
Improvements:
- Add METEOR_PROFILE instrumentation to the shouldWatch implementation.
- Stop exporting shouldWatch, since it is no longer used anywhere else in
the codebase.
- Return false early to avoid watching files inside the .meteor directory,
a significant shortcut.
- Allow watching files in application node_modules directories that are
not located directly in the root application directory (closes#10664).
Because json5 is more tolerant of non-standards-compliant input, it has no
trouble with \t tab characters outside of string literals, so this change
should fix issue #10688.
Note that json5 is already installed in dev_bundle/lib/node_modules/json5,
because it is a dependency of @babel/core, so we don't need to rebuild the
dev bundle immediately, though it would be a good idea to do so before the
next beta/RC release.
The previous implementation simply avoided calling watchSet.addFile for
potentially unused files, trusting that addFile would be called later if
the file was eventually used. However, this strategy left the contents of
watchSet.files incomplete for tasks such as IsopackCache._checkUpToDate,
which require full information about all files, even the ones that might
not be used by the bundle. The new strategy maintains metadata about
potentially unused files in a separate data structure, which will be
merged/cloned/serialized/deserialized along with other WatchSet data.
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.
