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.)
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.
Note that this test started as a test of parseStack when a filename
contained a colon, and it no longer tests that since around 1.1 we
started trying to avoid putting colons in generated filenames for
Windows compatibility. But it still caught this legacy handler bug!
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.
There are a few different times when we detect duplicate compiler
extensions.
(a) We detect them in Plugin.registerCompiler if a single
isopack itself registers duplicate extensions.
(b) When compiling a unibuild in compiler.compile, we check to see if a unibuild's
plugin-providing dependencies overlap.
(c) When preparing a unibuild for bundle-time source processing, we
check the same condition.
(Why do we need to re-check in (c)? If a unibuild was published and
passed (b) at publish time but is being bundled with different versions
of dependencies, it might fail (c).)
There were a few fixes here:
- In compiler.js (b), if we detected a duplicate extension, the code to get
the name of the conflict package was wrong and could throw.
- In compiler-plugin (c), we just weren't using buildmessage.
With just those fixes, we would actually see *both* kind of errors show
up if the error was in the app rather than a package, because
bundler.bundle didn't actually bail out on error after compiler.compile!
So we added that fix too, with a relatively conservative WatchSet.
"app/" in stack traces was an artifact of how we lay out files in the
built server, not how the source files are laid out, and isn't actually
as good as just using the source file name. Slava improved this on this
branch by just using the real file name. So the test (newly merged from
devel) needs to be improved to match.
While we're at it, let's test for filenames in a package.
Resolves these conflicts:
meteor
scripts/dev-bundle-server-package.js
scripts/dev-bundle-tool-package.js
tools/files.js
This requires building a new dev bundle, and moving the wrapCallSite
thing to source-map-retriever-stack.js.
- Uses Ben's meteor-babel npm package that has a default config
- From a checkout, uses the meteor-babel/register module and compiles at runtime
- When meteor-tool is published, precompiles the files
- Adds tests to make sure source maps work everywhere
Since we no longer statically analyze app code, a syntax error in app JS
is now a run-time error, not a build-time error, which broke those
tests. We still do some parsing on CSS as part of mergeCss, so bad CSS
will serve the same purpose.
Also combine the two coffee registerCompiler calls into one
it's a bad on-disk cache that should be improved to not write out all
the unchanged files every time too. but the tests do show that it skips
the unnecessary recompile
less doesn't use an on-disk cache yet
