Specifically, we want to avoid the situation where you run
'meteor show iron:router'
and then spend hours trying to figure out why Meteor can't process
your calls to, for example, BetterRouteController. The answer, of course,
might be that you are several versions behind and your version doesn't have
that export. We do not want to run the constraint solver to figure out what version
you are using; we played around with how to display this data and decided to just
be explicit about it.
My wording is intentionally vague. In reality, we take:
- the local version if one exists OR
- the latest mainline version, which a non-pre-release non-unmigrated(?) version.
- the latest version that we are showing iff there is no mainline version.
- for releases, we take the latest recommended version
This set of rules is much more complicated than the reality. The reality is pretty
intuitive. We don't want to dwell on what these rules are, just get the general idea across.
This commit is based on the following design document:
https://mdg.hackpad.com/Creating-and-Updating-Docs-0ZyyDcSZDxp,
and some other stuff from here: https://mdg.hackpad.com/Meteor-Long-Description-wGZ1vIOwVlF
and was code reviewed here: https://github.com/meteor/meteor/pull/3375
It does the following:
- Allow the user to specify package documentation in Package.Describe.
We will take the README.md file by default, to make the transition easier.
Users can specify ‘documentation: null’ to not submit a README.md
- From that documentation, extract the section between the first and second header
to use as the long form description for the package.
- Upload the documentation to the server at publish-time. Allow metadata changes with ‘publish —update’.
- Change the default package skeleton to include the README.md file.
Also, changes the skeleton to have fewer useless placeholders in Package.describe values.
- Fix a minor bug where Git did not show up when running ‘meteor show’ on local packages.
A note on ‘documentation: null’ and blank documentation — we don’t let maintainers upload
blank README.md files, because we want to encourage people to fill them out. (Instead,
we allow a ‘documentation: null’ as an override) This is a UX issue! It is not a technical thing.
There is more discussion and code review in: https://github.com/meteor/meteor/pull/3375
This is a thing that I wanted to try -- running 'meteor show' in a
package directory shows you that version's data.
- You might want to run 'meteor show' to get export or dependency
information on a local package, instead of looking through the
package.js file.
- Before publishing your package, or updating its metadata, you might
want to make really sure that its longform description looks good
in 'meteor show'. Hopefully it does! I would want to check.
Running 'meteor show <name>@local' from a package directory feels
slightly janky to me.
- Other commands in the publiction workflow read 'package.js' to figure
out your package name. It feels weird to type it out.
- Many package names don't correspond to the directory name. It is good
to help the user spend less time inspecting package.js files for
obvious information.
This has bothered me a lot during testing, which is not a normal workflow.
I might be somewhat biased here, in a way that normal users would not be.
There is a minor inefficiency around retrieving a local version record twice,
but I think that it is worth it for code simplicity/readability/etc.
The ‘show’ command has been completely rewritten. It has different output
and now does the following:
- Interacts with local package versions. Checks in the local package catalog, and
returns the local versions along with the server versions. When ‘meteor show’ is
run with a specific version request (‘meteor show foo@<version>’), default to
showing the local package version (but show a message that a server version is
available). Running ‘meteor show foo@local’ will always show the local version
(useful for version-less local packages).
- Simplify the interface. Instead of various ‘show-*’ flags, we only have one: show-all.
By default, we only show the top 5 official (non-prerelease) unmigrated versions of a
package (+ local version, if applicable). This can be overridden with ‘show-all’, and we
let the user know that more versions are available. For releases, ‘show-all’ will show
non-recommended releases.
- Display publication time for non-local package versions. This makes it easier to run
‘meteor show <name>’ and see if <name> is actively maintained. For local packages,
we display the root directory (useful for large apps or running with the
LOCAL_PACKAGE_DIRS variable, for example).
- For non-local package versions, show if the version is ‘installed’ (downloaded into the
warehouse). This involved minor changes to tropohouse.js. The idea is that this should
give a pretty good clue whether the version can be added offline.
- Show version dependencies. This should help the user understand, track down and
debug constraint solver failures.
- Do not show version architectures except in —ejson mode.
- Allow an ‘—ejson’ flag to get the output in EJSON format. That should make scripting
easier. (As a bonus, for release versions, the EJSON output acts as a nice template
for the release configuration file.)
The search command now does the following:
- Interacts with local package versions. Specifically, local versions override equivalent
server versions. Also, ‘search’ works on local packages (so, for example,
‘meteor search troposphere’ inside the package server app will give you the troposphere
package).
- Allows an ‘—ejson’ flag to get the outout in EJSON format.
Minor changes to some minor testing infrastructure:
- A new skeleton package, package-for-show. Its versions contain different
values for various metadata, so we can test that metadata comes from
the right version.
- In several places, replace the pattern of copying around
package.js files with using the replace function on a placeholder
string. (Mostly, as applied to package versions).
This is based on these hackpads: https://mdg.hackpad.com/Showing-Package-Metadata-HdGo3Lzx3hR
and https://mdg.hackpad.com/Meteor-Search-Output-1xxEzrAK9YU.
Reality is actually a little more complicated than this:
* We use your automatically detected local IP if you are running on device.
* We use 'localhost' if you are running on a simulator.
But it's hard to fit that in help text, and this is at least closer to
reality than it was before.
Summary:
Invoking `meteor shell` starts an interactive REPL for evaluating server-side code.
Shell commands are evaluated in the server process, so the shell's input and output have to be piped through a socket from/to the parent process that runs the `meteor shell` command. This separation accounts for most of the complexity of this diff, but the end result is pretty seamless: tab completion, history, ctlr-c and ctrl-d, etc. all work as expected.
Task: https://app.asana.com/0/15750483766338/16576093991355
Test Plan: Run `meteor run` in one terminal and `meteor shell` in another, evaluate some commands, and verify that the commands seem to be running the context of the server process. Also check tab completion and history, and ensure that the server is running simultaneously with the shell.
Reviewers: dgreenspan, avital, slava, emily, nim, sashko
CC: sashko
Differential Revision: https://phabricator.meteor.com/D837
This commit does the following:
- Introduces the get-machine command. This command contacts the build farm server
gets back a machine reservation and then opens a secure shell to the machine (Alternatively,
you can ask for a json). This also involved factoring out some commands to deal with authenticated
ddp from package-client into a more general auth-client.
- No longer publish binary builds in publish or publish-release; instead give the user a warning
to run get-machine and then publish-for-arch. Someone could ignore this: --existing-version and
publish-for-arch both publish binary builds, but you need to be at least somewhat familiar with
what you are doing to run them. Hopefully, you are running them from a certified build machine, but
if you are not, then, well, it is your package.
Stuff remaining:
- We are going to have a url to external documentation, but I haven't written it yet.
- We are currently talking to the test-build server, instead of the build server, so mac doesn't
work.
(Neither of those changes require significant tool changes)
Summary:
The `node-inspector` NPM package was added to the dev_bundle by this
recent commit: 64a624ae5c
Task: https://app.asana.com/0/15750483766338/16241466809965
Test Plan:
Add `debugger` statements to server code, run `meteor debug`, visit the
node-inspector URL in a browser, continue the application, and verify that
the debugger stops at the `debugger` statements that were set.
Reviewers: nim, slava, emily, avital, dgreenspan
CC: sashko
Differential Revision: https://phabricator.meteor.com/D827
--no-server was broken as of recently and not trivial to
fix. Instead, if you want to do a mobile build that connects to
something other than your local development server, use --mobile-port,
and your local development server will just listen on localhost:3000
as usual.
