Previously, when building a JavaScript bundle for the client, if a
package.json file had a string-valued "browser" field, we would replace
the value of the "main" field of the bundled package.json module with the
value of the "browser" field. This trick was important because it allowed
an npm package to have a different entry point on the client than it had
on the server.
However, that approach became inconsistent if the package.json file was
also explicitly imported as a module, because the package.json stub used
for module resolution prevented the real contents of package.json from
getting bundled, and disagreed with the original package.json module about
the value of the "main" field.
To resolve that inconsistency, it seems better to avoid modifying the
"main" field of package.json modules, and instead rely on the runtime
module system to make sense of the "browser" field, regardless of whether
the package.json module is a stub used only for module resolution or
contains the full contents of the original package.json file.
The ability to understand "browser" fields of package.json modules was
introduced in install@0.8.3:
377d1a3b51
This is potentially a backwards-incompatible change for developers using
this version of `ImportScanner` and `Resolver` who have not yet upgraded
their `modules-runtime` package to at least version 0.7.8. The solution is
to upgrade `modules-runtime`, though it would be nice to enforce that
better somehow.
Make the error message displayed to the developer more helpful in a situation like meteor/meteor#7859 where the `package.js` inadvertently referred to an imProPeRly-CaSeD version of the file it was importing.
No functionality change, just developer experience.
Fixes#7859
Tiny fix for an old issue where the console output would get corrupted when running `meteor admin set-unmigrated` or `meteor admin change-homepage` due to missing newline on `rawInfo` command.
Fixesmeteor/meteor#4054
This fixes a regression caused by 88d43a0f16 which is demonstrated in meteor/meteor#7849.
Essentially, with the current implementation some Cordova build elements are "stale" when the build is copied. For example, if you execute a `meteor run ios` and then `meteor build . --server=http://example.com/` (note: `example.com`) the `config.xml` (`<access origin />`), the boilerplate HTML (`__meteor_runtime_config__`) and other elements of the bundle (`Info.plist` on iOS) will still contain the previously used `http://<local_ip>:3000` address instead of `http://example.com` as they should.
Additionally, it would appear that it's impossible to actually checkout a project and immediately run `meteor build` without running `meteor run (android|ios)` first.
Various work-arounds for this seem to exist, such as running `meteor build` twice, or running `meteor run --server=http://production.com` first.
Ultimately, this is occurring because the bundle is being copied before the Cordova `prepareForPlatform` occurs which I believe was not intended.
There is already a test in place which fails without this fix, but marked as `slow` and therefore not executed on CircleCI. Specifically, `cordova builds with server options` would have caught this. Forcibly running this test locally now passes with this change.
Fixesmeteor/meteor#7849Fixesmeteor/meteor#7291Fixesmeteor/meteor#6756
Previously, the width (or "columns") for the readline shell was being obtained on the server. This causes problems for clients which are connecting to the server which are sized differently.
The client will still have problems if they resize AFTER they are connected to the REPL, but at least they have the option of being a different size.
A more complete solution would be to have the client listen on process.stdout "resize" and pass that to the server when it occurs, but I'm not sure of an easy way to do that with the current communication (perhaps pause-reconfigure-unpause?).
Fixesmeteor/meteor#5346
Although I have said I do not think Meteor should run `npm install`
automatically to update application node_modules, my real concern is that
Meteor should not interfere with your preferred node_modules-related
workflow, be it npm, npm-shinkwrap.json, yarn, yarn.lock, checking your
node_modules into git/mercurial/cvs, or whatever other scheme you have.
Automatically installing node_modules from the default package.json file
when a new app is created will eliminate real confusion, and should not
interfere with any workflows, because there is no opportunity to establish
another workflow before Meteor runs `npm install` the very first time.
While not a Meteor bug, this makes the error message more helpful when a compiler tries adding an asset without data, as demonstrated in meteor/meteor#8034.
Thanks to suggestion by @sdarnell for this.
Closesmeteor/meteor#8034
See https://github.com/meteor/meteor/issues/6785
Basically,
```
new Array(249).join('\b')
```
is not a good idea for a carriage return. Code has been tested with CMD, PowerShell and PowerShell in Legacy Mode and seems to solve the issue.
