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.
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
tropohouse._extractAndConvert assumes that any sourceMapRoot here is a
string or is missing. We started making it null recently on devel but
that means if it gets published this way, existing Windows tools will
crash on colon conversion.
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.
claim is a command related to the transition of 'meteor deploy' from
passwords to Meteor Accounts in Feb 2014. I already removed the real
tests of claim 8 months ago in 27d67fe because they were too slow. The
remaining tests test error cases and tend to fail due to Meteor
Developer Accounts being slow. Might as well remove; they don't test
anything we really care about.
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.
