This package will be installed by default for all new apps and packages.
Passing the {transpile:false} option to api.addFiles makes it possible for
a dependent package to specify that some files should not be processed
through babel-compiler.
Add new batch plugin APIs to Isobuild
New `Plugin.registerCompiler`, `Plugin.registerLinter`, and
`Plugin.registerMinifier` plugin methods.
* `registerCompiler` replaces the now-deprecated `Plugin.registerSourceHandler`
and expands it to allow compilers which process more than one file at a time,
and which always run in the context of your app (instead of before publishing
a package). Compilers can use in-memory and on-disk caches, which are
automatically cleared if the compiler itself changes version or is rebuilt
(and on `meteor rebuild`). Compilers can register for specific filenames
in addition to extensions.
* `registerLinter` allows you to check code for style violations and other
warnings. Unlike compilers, multiple linters can apply to the same file and
linter violations do not prevent the app from building.
* `registerMinifier` allows you to override the default minification logic. The
default minification logic (which includes CSS merging which runs even in
devel mode) now lives in the `standard-minifiers` package instead of
hard-coded in Isobuild). `standard-minifiers` is added to apps by
a new upgrader.
To use these new APIs, your package must depend on a special pseudo-package like
`isobuild:compiler-plugin@1.0.0`.
Static assets in `package.js` files must be explicitly declared with
`{isAsset: true}` (and you should choose client vs server). Existing
published packages will work, but their source will raise an error asking you
to add the flag.
`api.addFiles('foo.css')` without explicitly including `'client'` used to also
add `foo.css` as a server-side static asset. (This affected any handler using
archMatching, such as most CSS compilers and the templating `*.html` handler.)
Now, if a file is handled by a legacy source handler (or new compiler plugin) on
a subset of arches, it is *ignored* on other arches instead of treated as a
static asset. (This did not affect files in apps.)
New `meteor lint` command.
`meteor run`, `test-packages`, and `debug` display linter warnings by
default; this can be turned off with the `--no-lint` option.
Isopacks built by Isobuild are in a newer format, `isopack-2` (which contain
`isopack-2-unibuild` unibuilds). These can contain `source` resources (as well
as css/js, but those only come from legacy source handlers) and do not contain
`prelink` resources. They also don't contain a list of package variables,
because that is determined after running compiler plugins in the context of an
app. When possible, isopacks that are published to Atmosphere or placed in the
tropohouse also contain `isopack-1` data for older Isobuild versions to use.
The Windows-only colon conversion done when downloading packages to tropohouse
is skipped for `isopack-2` packages.
New `jshint` linter plugin package. (This package is currently in the core
release, but we may change our mind about this before the next Meteor release.)
`less` and `stylus` imports may cross package boundaries: `@import
"{packagename}/foo/bar.less";`.
In addition to the existing rules where files named `*.import.less` or
`*.lessimport` are not processed as "root" files, files in any subdirectory
named `imports` or tagged with `{isImport: true}` in `api.addFiles` are also
treated as "import-only" files and are not processed as root files.
The same goes for `stylus`.
In-memory and on-disk caches have been added to `coffeescript`, and
`less`. In-memory caches have been added to `stylus` and `templating`.
The `templating` package now detects duplicate `body` attributes across packages.
The default CSS minifier in `standard-minifiers` splits the merged CSS into
multiple files to keep each under the limit for maximum rules per file in IE.
We only prepend an anti-XSSI `)]}'` to source maps in production mode.
In `meteor run`, when rewriting the app bundle, the bundler defaults to
overwriting an existing app bundle instead of creating a new directory from
scratch. This behavior can be disabled by setting
`$METEOR_DISABLE_BUILDER_IN_PLACE`.
Version Solver: optimize the case where the constraint solver is called twice in
a row with the same input.
`linker` does more in-memory caching.
`sourceMap` can be now be specified to compiler plugins (and legacy source
handlers) as a JSON object as well as its stringified form
The URL used for original sources in source maps now begins with
`meteor://{PERSONAL COMPUTER EMOJI}app`, to make them more distinctive from the served files.
`linker` uses source maps to reflect the initial closure added around each file.
`WatchSet`s can now contain specific filenames that we expect to see in a
directory. Unlike `include` regexps, these take precedence over `exclude`
patterns.
- `source-map-support` to a fork of 0.3.2 (I think it was upgraded on devel too)
- `stylus` to a fork of 0.51.1 (from 0.46.3)
- `css-parse` to 2.0.0 (from an unreleased commit)
- `css-stringify` to 2.0.0 (from an unreleased commit)
- `less` to 2.5.0 (from 1.7.4)
@dgreensp:
The more I think about it, the more I don't like naming a directory
after a singular noun like `import`. We have `packages/` already,
and I want to put my modules in a directory called `modules/`, not
`module/`, just like I don't want to put my assets in `asset/`, or
my stylesheets in `stylesheet/`, etc. It's ok to have a singular
suffix and a plural directory name: to have `.import` files go in
`imports` or `.template` files go in `templates`. Directory names
like `doc` and `lib` follow an old Unix convention of three-letter
names. And if the `import` directory name is actually a verb, not a
noun, that is confusing because putting files in the `import`
directory does not import them. It just causes them to be
considered imports (noun).
In addition to the old `*.lessimport` and `*.import.less` mechanisms for
telling the `less` package that a file isn't a root, you can also put it
in an `import` subdirectory or pass `{isImport: true}` to
`api.addFiles`. We no longer will need to rename every less file when we
upgrade.
Next commit will revert the changes to examples and docs.
js-analyze is a tiny wrapper around esprima and escope. We don't use it
anywhere but in the tool. We even already use esprima in the tool
elsewhere.
It creates a fair amount of additional complexity. None of the other
isopackets are used as part of the isopack-building process, so it has a
bunch of random special case code for it.
This isn't as bad as it was with the older version of less we used where
they actually distributed *every version of less* in the dist directory,
not just the current one. But every byte counts!
(This is what Npm.strip is made for, but that doesn't support plugins.)
Linters run on one package at a time rather than one target at a
time. This is mostly because they need to run outside the context of
apps in various places (eg when you publish the package, though that's
currently unimplemented).
Previously, registerCompiler was enabled by the *real* package
`compiler-plugin`, which arranged to only be available in versions of
the tool that support registerCompiler via... well, mostly via wishful
thinking.
Now this is implemented via a fake package called
isobuild:compiler-plugin. "isobuild" is a real Atmosphere organization
that will never publish any packages. The tool pretends that packages
isobuild:compiler-plugin@1.0.0, isobuild:linter-plugin@1.0.0, and
isobuild:minifier-plugin@1.0.0 exist, and carefully arranges for them to
be avoided in the actual process of building and app; they just are
referenced in Version Solver.
When we add future features like this, users of this version of Meteor
who try to depend on packages that need the feature will get a nice
error message pointing to
https://github.com/meteor/meteor/wiki/Isobuild-Feature-Packages
Users of current versions of Meteor who try to depend on packages that
require isobuild:compiler-plugin will get a slightly confusing message
about isobuild:compiler-plugin not existing. Users of current versions
of Meteor who try to depend on packages only some of whose versions
require isobuild:compiler-plugin will get a version that doesn't require
it.
Rename 'mode' and 'minify' to 'minifyMode' consistently (including in
minifier plugin API).
Make minifyMode default to 'development' (fixes some other old bundler
tests).
This doesn't make bundler-assets pass but it gets farther along.
In the past, `api.addFiles('foo.gif')` would make foo.gif an asset if
there was no extension handler for gif active. In fact, it would make
it a dual client/server asset even if that was unintentional.
This led to a few problems:
(a) People often left out 'client' and ended up packaging an unnecessary
second server copy of the asset
(b) The implementation meant that `api.addFiles('foo.css')` would actually
add foo.css as a static asset on the server (this was already fixed
on batch-plugins via explicitly looking for wrong-arch
classifications)
(c) Now that we have linters, if a file is used by a linter but not by a
compiler (eg linter config files), there was no way to say in a
package "add this file, but just for linters, don't make it a static
asset too".
These are only really issues in packages, not apps. In apps, we avoid
them by only marking things as static assets if they are in public or
private (and not letting those things be considered as other kinds of
sources).
This is a backwards-incompatible change, but it does not affect apps or
published packages, just packages built from source.
Before this change, number of catch-up attempts was N*M, where N is number of
writes inside of the fence, and M is number of active observers on affected collections.
Every catch up issues yet another query to find the latest oplog entry.
It was extremely inefficient, in terms of both CPU usage and added latency.
After executing write-heavy methods, application process was occupied for many seconds
doing the same thing over and over again.
This change provides a performance improvement for all kinds of workloads.
This is in addition to registering for extensions. Note that only the
new SourceProcessor APIs allow this, not registerSourceHandler.
The filename in question is the basename of the file. The file can be
found in any directory in any package. If you want to be more picky,
you can just ignore other ones in your processFilesForTarget.
This introduces the SourceProcessorSet abstraction, which simplifies a
lot of repeated code around matching filenames with processors and
avoiding duplicates.
Missing tests.
See also #3985.
This will break the other verification email links but it will keep the
user document cleaner. The email will be verified anyways so who cares
that the other verification links isn’t working any more.
Closes#4626
If the same ProjectContext calls the PackagesResolver
multiple times and the ConstraintSolver.Input structure
is identical, reuse the same answer. We still ask the
tool for the catalog data, which currently goes to sqlite
(taking ~70ms in the app tested), but we skip creating a
CS.Solver and a Logic.Solver and running them (~450ms).
Note that if a new ProjectContext is created (not sure when
that happens?), there's no caching across that.
In the case when user or user:email scope wasn’t provided, use the
publicly visible email as before. In this case you can end up with not
having an email for GitHub accounts.
The email provided by the user info in the response from /user is the
publicly visible email, which a user can choose to not set.
GitHub accounts always have a primary email, so let’s use that one
instead.
There is 1 (1!) use of `$`, in
`click #configure-login-service-dialog-save-configuration`
(It probably could be rewritten to not use jquery though.)
Fixes#4616.
