@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.
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.
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
Specifically, ensure that we don't even include client-specific files in
the server WatchSet by making sure we pass a precise set of extensions
to initFromAppDir. We still also rule out wrong-arch files at a later
stage too (because sourceExtensions only affects initFromAppDir).
Without the change to compiler.js, the final test (adding
yet-another-root.main.less) restarts the server rather than printing
"Client modified -- refreshing".
mongo now transitively uses webapp (because ddp-server does) so we can't
really make an app with mongo and no webapp. This is a bit of a shame
and when we refactor the mongo package we should fix this... but until
then, let's just remove the no-longer-necessary main function and be OK
with this test running a pointless web server.
This test had been somewhat flaky. It seems to be less flaky now.
Changes include:
- Trying to not send the client->server logging RPC if the client is
about to reload due to autoupdate
- Making sure that the client doesn't send anything at all until a
little bit after starting, in order to make the ordering of messages
between tool-printed and server-printed messages more predictable
Also updated from standard-app-packages to meteor-tool.
`meteor run` doesn't always write changes to `.meteor/versions`: it only
does so if its release (or checkout-ness) matches `.meteor/release`. So
it preferred to just remember the value of `.meteor/versions` from
rebuild to rebuild rather than forgetting what it knew and re-reading
the possibly-not-updated file.
However, if some other process changes `.meteor/versions`, it would
ignore that change. With this fix, if `.meteor/versions` changes then
that is considered to be the previous versions list, not the last
version list from the same process. For example, this would commonly
happen due to using `meteor update` to update packages (without changing
the tool, which would cause the runner to stop).
Fixes#3582.
Specifically, Mongo.Collection objects on the server now have
rawCollection and rawDatabase methods.
You can use MongoInternals.NpmModules.mongodb.version to tell what
version of the mongodb npm module is the backend for HTTP.call. This
version may change incompatibly from version to version of Meteor; use
at your own risk. (For example, we expect to upgrade from the 1.4.x
series to the 2.x series in the not-too-distant future.)
Fixes#3640.
Previously, we would register the circular dependency error properly
with buildmessage, but then try to build the package with a circular
dependency anyway, leading to a crash.
Fixes#3280.
This reimplements functionality that had been removed as part of the
`isopack-cache` branch refactoring.
Information about package changes is encapsulated inside a
PackageMapDelta object on the ProjectContext. It is the responsibility
of the command that prepares the ProjectContext to choose to call
projectContext.packageMapDelta.displayOnConsole at the appropriate time
if it wishes to display changes.
Part of #3006.
We don't have a way to HCP a changed set of plugins or platforms, so
just exit and ask the user to re-run. There are probably some cases
where we don't have to exit (e.g. if you add the android platform, we
probably don't need to exit out of 'meteor run ios'), but we exit in all
cases for simplicity.
