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)
For some reason I decided that tests should, on cleanup, stop their
runs *and not wait for the stop to take effect* before running the next
test. Maybe this could be reconsidered but for now, explicitly stop this
run (and wait) so the next test (npm: npm) doesn't fail.
@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.)
There were a few problems here:
- compiler.lint actually did things that could seriously fail (eg loading
plugins) but used its buildmessage context to return *linter
warnings*. So actual errors got lumped in with warnings and didn't
prevent builds. Fixed this by changing compiler.lint to return linter
warnings as a return value and use its implicit buildmessage context
only for build errors
- We weren't checking for errors after compiler.getMinifiers even though
that loaded plugins and could fail
- We were using _.isEmpty(app.sourceProcessors.linter) to decide in
lintBundle if we should say "no linter warnings" or "no linters were
run", but this is a SourceProcessorSet now, not a dictionary, so we
should have used the isEmpty method instead (so we were getting
unnecessary "No linting errors" messages when there were no linters)
- compiler.compile still tried to run getSourcesFunc even if
initializing the SourceProcessorSets failed
- Printing linter warnings in the runner looked different depending on
whether it was right after doing a client refresh or not
- We were doing a temporary log of "Linting your app" and immediately
logging "Linted your app". The point of temporary logs is to display
while long processes run, but since linting is integrated, this didn't
really make sense. (Really we need to better integrate the progress
bar and runlog, since progress fulfills most of the needs formerly
done by the runlog.)
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).
- Make the return value be an object with class (and more error
checking)
- Rename legacyHandler type to legacy-handler (to match wrong-arch)
- Fix `isTempate` typo which probably broke loadOrderSort for legacy
handlers
