Since server/.bundle_version.txt is mostly used to determine the node
version, writing it more directly can help too.
(Arguably this should be MIN_NODE_VERSION rather than process.version
but that value is not easily accessed.)
When we download a package that's only isopack-1, we're supposed to
write it as a "fat" isopack-1/isopack-2 package, by using the same
includePreCompilerPluginIsopackVersions flag used for publishing
packages. However, the internal representation of the "prelink" resource
contained in legacy packages didn't have a flag set that is later used
to see if includePreCompilerPluginIsopackVersions is allowed to be
effective. This meant that we'd download packages published as
isopack-1-only and save them as isopack-2-only. And then old meteor
releases would fail to use them.
Fixes#4923.
The compiler inserts code that imports the exports of used packages.
It's important that we don't do this for the exports of used
debugOnly and prodOnly packages, because the inserted code will
fail at runtime if the packages are not linked in because we aren't
in dev mode or aren't in prod mode.
It's very useful to be able to include code only in production. It's
useful for React integration, but presumably also for many apps.
* Add prodOnly boolean flag alongside debugOnly in Package.describe
* Packages the set prodOnly to true auto-depend on isobuild:prod-only
(making them error in the old tool where prodOnly isn't supported)
* The `includeDebug` boolean build option is replaced by a string
named buildMode, which can be 'development' or 'production', just
like minifyMode.
Tested by self-test.
Band-aidy, but fixes the case when two packages add the same plugin with
the same version that can't be parsed by semver (like github url).
For some reason, after the build plugins refactoring the same plugin
from the same package can now be added twice from `webapp`.
Since this feature is not well designed to begin with, decided to spend
too much time investigating it.
Also, "marketing material" doesn't seem like an accurate description of the page on the Meteor site as it's more of a high level description of the component.
The Babel parser is faster, it has to be installed (unlike Esprima, which
can be removed after a few more changes like this), and better matches the
parsing we do for ECMAScript transpilation.
- Upgrade to a newer (unreleased) version which supports
function k({} = {}) {}
and doesn't also crash
- Filter out boring warnings
- Don't use ES7 syntax that JSDoc doesn't support in one file that
has JSDoc in it
I thought we could rely on isobuild:compiler-plugin for this, but it's
not good enough: a package could have dependencies that are satisfiable
without choosing a dependency version with a compiler plugin, yet choose
that dependency version at publish time and become ineligble for legacy
builds.
