New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release 1.5 #8327

Merged
merged 263 commits into from May 30, 2017

Conversation

Projects
None yet
@benjamn
Member

benjamn commented Feb 7, 2017

Just as Meteor 1.4.2 took aim at rebuild performance, Meteor 1.5 will be all about production app performance, specifically client-side application startup time.

The banner feature of this effort will be first-class support for dynamic import(...), which enables asynchronous module fetching (sometimes referred to as "code splitting"). Jump to this comment for an overview of how it works.

As usual, this release will include any bug fixes since Meteor 1.4.3, though special attention will be paid to pull requests and issues that affect the performance of running applications.

You can update to the latest release candidate final release by running:

meteor update --release 1.5

benjamn added some commits Feb 6, 2017

Enable immutable caching for dynamic modules.
Even though localStorage is a synchronous API, I wrote this code in an
asynchronous style so that we can easily switch to an async API when/if
that becomes preferable.

While localStorage has stricter size limits than IndexedDB, retrieving
data from IndexedDB is unbelievably slow (~10ms for each cache.check
call). When developing locally, that delay pretty much destroys any
benefit from caching.

@benjamn benjamn added this to the Release 1.5 milestone Feb 7, 2017

@benjamn benjamn added the in progress label Feb 7, 2017

@laosb

This comment has been minimized.

Show comment
Hide comment
@laosb

laosb Feb 8, 2017

Collaborator

Good to see the first beta! Is code splitting available at this time?

Collaborator

laosb commented Feb 8, 2017

Good to see the first beta! Is code splitting available at this time?

benjamn added some commits Feb 8, 2017

Disable optimistic caching for `meteor --get-ready` on Circle CI.
We (@abernix and I) suspect the intermittent "died unexpectedly" failures
of `meteor --get-ready` on Circle CI are due to hitting their (low) limit
on the maximum number of open files.

Although optimistic caching speeds up rebuilds considerably, it doesn't do
much for initial builds, and it definitely keeps more files open.
Disabling it here seems worth a try.
@benjamn

This comment has been minimized.

Show comment
Hide comment
@benjamn

benjamn Feb 8, 2017

Member

@laosb It should be working (after you meteor add dynamic-import), but unfortunately there seem to be some problems with the published beta releases. Specifically, import(...) isn't getting compiled into module.dynamicImport(...). I'll have to take a closer look at that tomorrow!

Member

benjamn commented Feb 8, 2017

@laosb It should be working (after you meteor add dynamic-import), but unfortunately there seem to be some problems with the published beta releases. Specifically, import(...) isn't getting compiled into module.dynamicImport(...). I'll have to take a closer look at that tomorrow!

@benjamn

This comment has been minimized.

Show comment
Hide comment
@benjamn

benjamn Feb 8, 2017

Member

Okay! The problem was that I hadn't republished the ecmascript package as part of the beta release. Only babel-compiler had really changed, but ecmascript has a dependency on babel-compiler, so it needed to be republished as well.

With that minor snag out of the way, I'm happy to announce that you can try import(...) yourself right now (on Mac and Linux; still waiting for Meteor 1.4.2.6 to finish publishing on Windows).

Just run the following commands:

meteor create --release 1.5-beta.2 dynamic-import-test
cd dynamic-import-test
meteor add dynamic-import
meteor npm install --save react

Now, in dynamic-import-test/client/main.js, you can import react asynchronously when the "Click me" button is pressed:

Template.hello.events({
  'click button'(event, instance) {
    // increment the counter when button is clicked                                                                                                                                                                                                                                                                                                                         
    instance.counter.set(instance.counter.get() + 1);
    import("react").then(React => {
      console.log(React);
    });
  },
});

You can inspect the websocket frames in the "Network" tab of the Chrome Dev Tools to see that the code is being fetched over the network the first time the button is pressed.

In addition to importing npm packages, try creating a file called client/imports/dynamic.js and then import("./imports/dynamic.js").then(d => ...) in client/main.js. It's important that it's in an imports directory so that it won't be eagerly imported until you import(...) it.

The same syntax works on the server, though of course it's more interesting on the client.

Member

benjamn commented Feb 8, 2017

Okay! The problem was that I hadn't republished the ecmascript package as part of the beta release. Only babel-compiler had really changed, but ecmascript has a dependency on babel-compiler, so it needed to be republished as well.

With that minor snag out of the way, I'm happy to announce that you can try import(...) yourself right now (on Mac and Linux; still waiting for Meteor 1.4.2.6 to finish publishing on Windows).

Just run the following commands:

meteor create --release 1.5-beta.2 dynamic-import-test
cd dynamic-import-test
meteor add dynamic-import
meteor npm install --save react

Now, in dynamic-import-test/client/main.js, you can import react asynchronously when the "Click me" button is pressed:

Template.hello.events({
  'click button'(event, instance) {
    // increment the counter when button is clicked                                                                                                                                                                                                                                                                                                                         
    instance.counter.set(instance.counter.get() + 1);
    import("react").then(React => {
      console.log(React);
    });
  },
});

You can inspect the websocket frames in the "Network" tab of the Chrome Dev Tools to see that the code is being fetched over the network the first time the button is pressed.

In addition to importing npm packages, try creating a file called client/imports/dynamic.js and then import("./imports/dynamic.js").then(d => ...) in client/main.js. It's important that it's in an imports directory so that it won't be eagerly imported until you import(...) it.

The same syntax works on the server, though of course it's more interesting on the client.

@klaussner

This comment has been minimized.

Show comment
Hide comment
@klaussner

klaussner Feb 8, 2017

Collaborator

Dynamic imports are working great so far! 😍 Just two remarks:

  • If an npm package is imported by both an eagerly loaded and a dynamically imported module, import(...) throws Uncaught (in promise) Error: Cannot find module '<npm package>'. Reproduction here.

  • Given that mostly large applications will benefit from dynamic import, the small localStorage quotas granted by browsers (5 MB on Chrome, 2.5 MB on Safari) could be a problem. Even more so if localStorage is used for application data as well.

Collaborator

klaussner commented Feb 8, 2017

Dynamic imports are working great so far! 😍 Just two remarks:

  • If an npm package is imported by both an eagerly loaded and a dynamically imported module, import(...) throws Uncaught (in promise) Error: Cannot find module '<npm package>'. Reproduction here.

  • Given that mostly large applications will benefit from dynamic import, the small localStorage quotas granted by browsers (5 MB on Chrome, 2.5 MB on Safari) could be a problem. Even more so if localStorage is used for application data as well.

@benjamn

This comment has been minimized.

Show comment
Hide comment
@benjamn

benjamn Feb 8, 2017

Member

@klaussner I tried using IndexedDB (via https://npmjs.org/package/localforage), but access times were unbelievably slow (5-10 milliseconds per query).

Any thoughts about alternative client storage mechanisms? It's possible we could just rely on HTTP caching, though that would mean not using a web socket.

I suppose we could use IndexedDB if we loaded the manifest (module identifiers, hashes) into memory eagerly when the application started (probably in this file). That way we wouldn't have to pay the API tax every time we check the cache.

Member

benjamn commented Feb 8, 2017

@klaussner I tried using IndexedDB (via https://npmjs.org/package/localforage), but access times were unbelievably slow (5-10 milliseconds per query).

Any thoughts about alternative client storage mechanisms? It's possible we could just rely on HTTP caching, though that would mean not using a web socket.

I suppose we could use IndexedDB if we loaded the manifest (module identifiers, hashes) into memory eagerly when the application started (probably in this file). That way we wouldn't have to pay the API tax every time we check the cache.

benjamn added some commits Feb 8, 2017

Rename `modules` to `real` in modules-runtime/meteor-install.js.
I think `real` is a better antonym for `meta`, and I appreciate that
`real` and `meta` are both four letters long.
Copy "main" and "browser" from non-dynamic package.json files.
Fixes the first problem reported by @klaussner in this comment:
#8327 (comment)
Fix tests by adding //# sourceMappingURL= only to dynamic files.
Also, the regular expression for removing existing source map comments now
matches only if the comment starts at the beginning of a line, following
previous behavior more closely.

To get this exactly right, we would need to tokenize the source to avoid
matching comments in string literals, for example, but that's hard because
this logic needs to work for multiple file types, not just JavaScript.
@tcastelli

This comment has been minimized.

Show comment
Hide comment
@tcastelli

tcastelli Feb 9, 2017

Contributor

With the proposed solution of in-memory management of identifiers and hashes, maybe something like this could be useful https://github.com/dumbmatter/fakeIndexedDB

Also searching around I found these, which have adapters to persists with indexedDB but use indexes for fast queries once sync is done.

Contributor

tcastelli commented Feb 9, 2017

With the proposed solution of in-memory management of identifiers and hashes, maybe something like this could be useful https://github.com/dumbmatter/fakeIndexedDB

Also searching around I found these, which have adapters to persists with indexedDB but use indexes for fast queries once sync is done.

@laosb

This comment has been minimized.

Show comment
Hide comment
@laosb

laosb Feb 9, 2017

Collaborator

Hooray! Good to see that!

Actually we should have a suggested application structure for dynamic imports

Collaborator

laosb commented Feb 9, 2017

Hooray! Good to see that!

Actually we should have a suggested application structure for dynamic imports

@karldanninger

This comment has been minimized.

Show comment
Hide comment
@karldanninger

karldanninger Feb 9, 2017

Weeeeeee!!!!! This is fantastic news! Thanks @benjamn <3

karldanninger commented Feb 9, 2017

Weeeeeee!!!!! This is fantastic news! Thanks @benjamn <3

@benjamn

This comment has been minimized.

Show comment
Hide comment
@benjamn

benjamn Feb 9, 2017

Member

Question: should the localStorage/IndexedDB caching be enabled in development, or only in production? It seems to complicate the mental model in development, especially if you're developing multiple apps using the same storage domain (http://localhost:3000), and it doesn't really save time because everything's loaded from localhost.

Member

benjamn commented Feb 9, 2017

Question: should the localStorage/IndexedDB caching be enabled in development, or only in production? It seems to complicate the mental model in development, especially if you're developing multiple apps using the same storage domain (http://localhost:3000), and it doesn't really save time because everything's loaded from localhost.

@tcastelli

This comment has been minimized.

Show comment
Hide comment
@tcastelli

tcastelli Feb 9, 2017

Contributor

What about only enabling localStorage/IndexedDB while running with --production (or in production of course)?

Contributor

tcastelli commented Feb 9, 2017

What about only enabling localStorage/IndexedDB while running with --production (or in production of course)?

@benjamn

This comment has been minimized.

Show comment
Hide comment
@benjamn

benjamn Feb 9, 2017

Member

@tcastelli yep, that's what I'm thinking

Member

benjamn commented Feb 9, 2017

@tcastelli yep, that's what I'm thinking

@sebakerckhof

This comment has been minimized.

Show comment
Hide comment
@sebakerckhof

sebakerckhof Feb 9, 2017

Contributor

What's the strategy for cordova apps?

Contributor

sebakerckhof commented Feb 9, 2017

What's the strategy for cordova apps?

Overwrite implicit modules only if they are package.json files.
Implicit empty stub CSS modules added in addStylesheet in
compiler-plugin.js were being overwritten with actual CSS module code,
thanks to logic intended to support replacing package.json stubs with
their actual contents.

The meaning of "implicit" is somewhat overloaded: for package.json
modules, it means the module is a minimal stub (just the "name",
"version", and "main"/"browser" fields) that should be replaced if ever
explicitly imported. For empty stub CSS modules, it means the module
should yield to any actual modules added via addJavaScript.
@Primigenus

This comment has been minimized.

Show comment
Hide comment
@Primigenus

Primigenus Feb 9, 2017

Contributor

Re: client-side storage, Service Worker's Cache API would be ideal in the browsers that support it (Chrome, Firefox & Opera), since it's designed to cache a request and provide an associated response, which maps well to the dynamic import's path or package name argument. Fallback could then be an IndexedDb equivalent for browsers that don't support it, replacing that with native support as that situation improves.

I'm also curious whether Meteor can install a service worker with relevant resources pre-cached just after the app boots, but before the code requests them, as sending a network request for 500K of javascript when the user clicks a button doesn't seem that much better than loading it up front. If we want Meteor 1.5 to have better performance characteristics, aiming for PRPL, which advocates for initially loading the app shell and then loading remaining content with fetch requests, may be a good starting point.

What's the plan for dynamic imports in packages? Ideally, if I meteor add accounts-ui but the current screen (currently executing code) doesn't use {{> loginButtons}}, it wouldn't get imported.

Contributor

Primigenus commented Feb 9, 2017

Re: client-side storage, Service Worker's Cache API would be ideal in the browsers that support it (Chrome, Firefox & Opera), since it's designed to cache a request and provide an associated response, which maps well to the dynamic import's path or package name argument. Fallback could then be an IndexedDb equivalent for browsers that don't support it, replacing that with native support as that situation improves.

I'm also curious whether Meteor can install a service worker with relevant resources pre-cached just after the app boots, but before the code requests them, as sending a network request for 500K of javascript when the user clicks a button doesn't seem that much better than loading it up front. If we want Meteor 1.5 to have better performance characteristics, aiming for PRPL, which advocates for initially loading the app shell and then loading remaining content with fetch requests, may be a good starting point.

What's the plan for dynamic imports in packages? Ideally, if I meteor add accounts-ui but the current screen (currently executing code) doesn't use {{> loginButtons}}, it wouldn't get imported.

Make sure dynamic-import package has Promise polyfill.
I might not have noticed this, except that PhantomJS still does not
provide a native Promise constructor.
@fermuch

This comment has been minimized.

Show comment
Hide comment
@fermuch

fermuch May 30, 2017

So far, everything is working OK with rc 12.

fermuch commented May 30, 2017

So far, everything is working OK with rc 12.

@benjamn

This comment has been minimized.

Show comment
Hide comment
@benjamn

benjamn May 30, 2017

Member

@vladejs Scratch that, I figured out how to get readable stack traces: bfc79ee

And, yes, by the way, it could have waited until after the release, but I went ahead and included it because it seems extremely low-risk (in part because we can always fix it later).

Member

benjamn commented May 30, 2017

@vladejs Scratch that, I figured out how to get readable stack traces: bfc79ee

And, yes, by the way, it could have waited until after the release, but I went ahead and included it because it seems extremely low-risk (in part because we can always fix it later).

@szchenghuang

This comment has been minimized.

Show comment
Hide comment
@szchenghuang

szchenghuang May 30, 2017

I am with @vladejs and wishing it to be prioritized.

I have been pointed to inaccurate lines when run time errors occur since beta. I have been kind of ignoring the line indicator for months. Thank that I keep each of my React components light and separate in its own file. An accurate file indicator to a small file eases the problem, but it will not always be the case.

That is an important piece to dynamic-import IMHO.

szchenghuang commented May 30, 2017

I am with @vladejs and wishing it to be prioritized.

I have been pointed to inaccurate lines when run time errors occur since beta. I have been kind of ignoring the line indicator for months. Thank that I keep each of my React components light and separate in its own file. An accurate file indicator to a small file eases the problem, but it will not always be the case.

That is an important piece to dynamic-import IMHO.

@vladejs

This comment has been minimized.

Show comment
Hide comment
@vladejs

vladejs May 30, 2017

vladejs commented May 30, 2017

@benjamn

This comment has been minimized.

Show comment
Hide comment
@benjamn

benjamn May 30, 2017

Member

Yes, everything in this pull request is going into the official release (today, unless we hear a good reason for further delay).

Member

benjamn commented May 30, 2017

Yes, everything in this pull request is going into the official release (today, unless we hear a good reason for further delay).

@jamiter

This comment has been minimized.

Show comment
Hide comment
@jamiter

jamiter May 30, 2017

Contributor

Awesome work @benjamn! This is going to make a lot of anxious developers happy!

To be honest, those last improvements are going to make the first impression of 1.5 a lot better. Good stack traces and common.js support (a.k.a. 90% of npm) are very important. People have waited for this a long time and it would be a bummer if first impressions were ruined by these issues. So a week well spend if you ask me! 👍

Contributor

jamiter commented May 30, 2017

Awesome work @benjamn! This is going to make a lot of anxious developers happy!

To be honest, those last improvements are going to make the first impression of 1.5 a lot better. Good stack traces and common.js support (a.k.a. 90% of npm) are very important. People have waited for this a long time and it would be a bummer if first impressions were ruined by these issues. So a week well spend if you ask me! 👍

@szchenghuang

This comment has been minimized.

Show comment
Hide comment
@szchenghuang

szchenghuang May 30, 2017

Splendid achievement! This series of conversation is delightful. Can't wait to meteor update --release 1.5!

szchenghuang commented May 30, 2017

Splendid achievement! This series of conversation is delightful. Can't wait to meteor update --release 1.5!

benjamn added some commits May 30, 2017

Upgrade meteor-promise to version 0.8.4.
This is a change that was necessary on the wip-upgrade-to-node-6 branch,
and it seems better to ship it sooner rather than waiting:
d823812

@benjamn benjamn merged commit bf85eac into master May 30, 2017

4 checks passed

CLA Author has signed the Meteor CLA.
Details
ci/circleci Your tests passed on CircleCI!
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
@abernix

This comment has been minimized.

Show comment
Hide comment
@abernix

abernix May 30, 2017

Member

👏 🎉 🥇.⓹ 💥 Wooooohooooo! Hurrah! 💥 🥇.⓹ 🎉 👏

Member

abernix commented May 30, 2017

👏 🎉 🥇.⓹ 💥 Wooooohooooo! Hurrah! 💥 🥇.⓹ 🎉 👏

@d62remi

This comment has been minimized.

Show comment
Hide comment
@d62remi

d62remi May 30, 2017

👍👍👍

d62remi commented May 30, 2017

👍👍👍

@macrozone

This comment has been minimized.

Show comment
Hide comment
@macrozone

macrozone commented May 30, 2017

<3

@benjamn

This comment has been minimized.

Show comment
Hide comment
@benjamn

benjamn May 30, 2017

Member

The Meteor 1.5 release is now final, though you'll still need to run meteor update --release 1.5 to get it, rather than just meteor update. After the announcement blog post goes up tomorrow, we'll officially "recommend" the release, which will make meteor update work.

If you already miss living on the bleeding edge, now that Meteor 1.5 is out, there's a new edge to play with over here: #8728

Member

benjamn commented May 30, 2017

The Meteor 1.5 release is now final, though you'll still need to run meteor update --release 1.5 to get it, rather than just meteor update. After the announcement blog post goes up tomorrow, we'll officially "recommend" the release, which will make meteor update work.

If you already miss living on the bleeding edge, now that Meteor 1.5 is out, there's a new edge to play with over here: #8728

@willyb321

This comment has been minimized.

Show comment
Hide comment
@willyb321

willyb321 May 30, 2017

Woot! 🎉

willyb321 commented May 30, 2017

Woot! 🎉

@mjmasn

This comment has been minimized.

Show comment
Hide comment
@mjmasn

mjmasn May 31, 2017

Contributor

@abernix the new bundle-visualizer package is awesome!

Contributor

mjmasn commented May 31, 2017

@abernix the new bundle-visualizer package is awesome!

@sferoze

This comment has been minimized.

Show comment
Hide comment
@sferoze

sferoze May 31, 2017

@mjmasn how do you use this package? There is no info in the repo https://atmospherejs.com/meteor/bundle-visualizer

sferoze commented May 31, 2017

@mjmasn how do you use this package? There is no info in the repo https://atmospherejs.com/meteor/bundle-visualizer

@stubailo

This comment has been minimized.

Show comment
Hide comment
@stubailo

stubailo May 31, 2017

Contributor

You just add it I think! Then start your app.

Contributor

stubailo commented May 31, 2017

You just add it I think! Then start your app.

@mjmasn

This comment has been minimized.

Show comment
Hide comment
@mjmasn

mjmasn May 31, 2017

Contributor

@sferoze

meteor add bundle-visualizer then run meteor with --production

For two of our older apps I needed to meteor npm i -S meteor-node-stubs as well. Not sure if that's added automatically these days.

You also have to remove the bundle-visualizer package before deploying so I guess it's not totally ready for prime-time. Difficult one though because it has to run in production mode and can't tell if you're actually running locally with --production or actual production (although I'm sure there are ways to solve this).

Contributor

mjmasn commented May 31, 2017

@sferoze

meteor add bundle-visualizer then run meteor with --production

For two of our older apps I needed to meteor npm i -S meteor-node-stubs as well. Not sure if that's added automatically these days.

You also have to remove the bundle-visualizer package before deploying so I guess it's not totally ready for prime-time. Difficult one though because it has to run in production mode and can't tell if you're actually running locally with --production or actual production (although I'm sure there are ways to solve this).

@sferoze

This comment has been minimized.

Show comment
Hide comment
@sferoze

sferoze May 31, 2017

thanks @stubailo @mjmasn

I added it and it's awesome! Already helped me reduce the app size

sferoze commented May 31, 2017

thanks @stubailo @mjmasn

I added it and it's awesome! Already helped me reduce the app size

@dr-dimitru

This comment has been minimized.

Show comment
Hide comment
@dr-dimitru

dr-dimitru May 31, 2017

Contributor

Dynamic import() reduced our app size from ~4MB to ~800KB, awesome, thanks a lot MDG!
So solve this task quickly we've added dynamic import() support directly to flow-router - more info here

Contributor

dr-dimitru commented May 31, 2017

Dynamic import() reduced our app size from ~4MB to ~800KB, awesome, thanks a lot MDG!
So solve this task quickly we've added dynamic import() support directly to flow-router - more info here

@ducdev

This comment has been minimized.

Show comment
Hide comment
@ducdev

ducdev May 31, 2017

Incredible !

ducdev commented May 31, 2017

Incredible !

@michaelb-01

This comment has been minimized.

Show comment
Hide comment
@michaelb-01

michaelb-01 May 31, 2017

This looks great, is there an example project using angular (2 or 4) with Meteor 1.5 anywhere?

michaelb-01 commented May 31, 2017

This looks great, is there an example project using angular (2 or 4) with Meteor 1.5 anywhere?

@abernix

This comment has been minimized.

Show comment
Hide comment
@abernix

abernix May 31, 2017

Member

I've created (via 791d0cd) a README for bundle-visualizer on Atmosphere which provides information about how to use the bundle visualizer in conjunction with Meteor 1.5. Take a look at it and see if it provides more information and feel free to open a pull-request if you find any inaccurate information or something additional which might be helpful. The file can be found here in this repo.

/cc @sferoze

(And thanks to @mjmasn for providing the details above).

Member

abernix commented May 31, 2017

I've created (via 791d0cd) a README for bundle-visualizer on Atmosphere which provides information about how to use the bundle visualizer in conjunction with Meteor 1.5. Take a look at it and see if it provides more information and feel free to open a pull-request if you find any inaccurate information or something additional which might be helpful. The file can be found here in this repo.

/cc @sferoze

(And thanks to @mjmasn for providing the details above).

@vladejs

This comment has been minimized.

Show comment
Hide comment
@vladejs

vladejs May 31, 2017

Issue when upgrading from 1.5-beta.14 to 1.5 with a Buffer object.
deepinscreenshot20170531093748

Note: I use the uploader package ostrio:files. By using this package I had to npm i file-type fs-extra too. But in any case the above issue arises.

vladejs commented May 31, 2017

Issue when upgrading from 1.5-beta.14 to 1.5 with a Buffer object.
deepinscreenshot20170531093748

Note: I use the uploader package ostrio:files. By using this package I had to npm i file-type fs-extra too. But in any case the above issue arises.

@dr-dimitru

This comment has been minimized.

Show comment
Hide comment
@dr-dimitru

dr-dimitru May 31, 2017

Contributor

Hi @vladejs ,

Weird we don't use Buffer on the client see VeliovGroup/Meteor-Files#434 and #8645 (comment)

// this is an expensive polyfill for clientside Buffer usage
// but we recommend you refactor to remove this dependency
global.Buffer = global.Buffer || require("buffer").Buffer; // eslint-disable-line

// how to refactor
// you can easily drop a breakpoint on the error in your browser's inspector, then refresh the page to hit the breakpoint and see via the call stack which package is trying to use Buffer
// https://github.com/meteor/meteor/issues/8645

Hope this will fix it, I'm on major update of ostrio:files translating to ES6 (now it's CoffeeScript), so it should be fixed soon.

Contributor

dr-dimitru commented May 31, 2017

Hi @vladejs ,

Weird we don't use Buffer on the client see VeliovGroup/Meteor-Files#434 and #8645 (comment)

// this is an expensive polyfill for clientside Buffer usage
// but we recommend you refactor to remove this dependency
global.Buffer = global.Buffer || require("buffer").Buffer; // eslint-disable-line

// how to refactor
// you can easily drop a breakpoint on the error in your browser's inspector, then refresh the page to hit the breakpoint and see via the call stack which package is trying to use Buffer
// https://github.com/meteor/meteor/issues/8645

Hope this will fix it, I'm on major update of ostrio:files translating to ES6 (now it's CoffeeScript), so it should be fixed soon.

@p3pp8

This comment has been minimized.

Show comment
Hide comment
@p3pp8

p3pp8 May 31, 2017

** SOLVED **
Angular UIRouter 1.0.3 stopped working again after updating the project to release 1.5 and after these upgrades:

babel-compiler             upgraded from 6.18.2 to 6.19.1
boilerplate-generator      upgraded from 1.0.11 to 1.1.0
dynamic-import             added, version 0.1.0
ecmascript                 upgraded from 0.7.3 to 0.8.0
ecmascript-runtime         upgraded from 0.3.15 to 0.4.1
ecmascript-runtime-client  added, version 0.4.1
ecmascript-runtime-server  added, version 0.4.1
meteor-base                upgraded from 1.0.4 to 1.1.0
minifier-js                upgraded from 2.0.0 to 2.1.0
minimongo                  upgraded from 1.0.23 to 1.2.0
modules                    upgraded from 0.8.2 to 0.9.0
modules-runtime            upgraded from 0.7.10 to 0.8.0
mongo                      upgraded from 1.1.17 to 1.1.18
promise                    upgraded from 0.8.8 to 0.8.9
reactive-dict              upgraded from 1.1.8 to 1.1.9
standard-minifier-js       upgraded from 2.0.0 to 2.1.0
webapp                     upgraded from 1.3.15 to 1.3.16

SORRY, it was because of static templates, not depending of uiRouter or Meteor 1.5!!!
GREATE RELEASE!!!

p3pp8 commented May 31, 2017

** SOLVED **
Angular UIRouter 1.0.3 stopped working again after updating the project to release 1.5 and after these upgrades:

babel-compiler             upgraded from 6.18.2 to 6.19.1
boilerplate-generator      upgraded from 1.0.11 to 1.1.0
dynamic-import             added, version 0.1.0
ecmascript                 upgraded from 0.7.3 to 0.8.0
ecmascript-runtime         upgraded from 0.3.15 to 0.4.1
ecmascript-runtime-client  added, version 0.4.1
ecmascript-runtime-server  added, version 0.4.1
meteor-base                upgraded from 1.0.4 to 1.1.0
minifier-js                upgraded from 2.0.0 to 2.1.0
minimongo                  upgraded from 1.0.23 to 1.2.0
modules                    upgraded from 0.8.2 to 0.9.0
modules-runtime            upgraded from 0.7.10 to 0.8.0
mongo                      upgraded from 1.1.17 to 1.1.18
promise                    upgraded from 0.8.8 to 0.8.9
reactive-dict              upgraded from 1.1.8 to 1.1.9
standard-minifier-js       upgraded from 2.0.0 to 2.1.0
webapp                     upgraded from 1.3.15 to 1.3.16

SORRY, it was because of static templates, not depending of uiRouter or Meteor 1.5!!!
GREATE RELEASE!!!

@CaptainN

This comment has been minimized.

Show comment
Hide comment
@CaptainN

CaptainN May 31, 2017

Contributor

After upgrading to meteor 1.5 (from 1.5-rc.7), my app had been running with meteor-tool/1.4.x.x (as revealed by the path in my terminal title bar) - is that a problem? It would run meteor-tool/1.5.0.xxxx when doing an update.

I start meteor with meteor npm start which invokes the script "start": "meteor --settings settings-development.json" from package.json

I fixed it by uninstalling and reinstalling meteor from scratch.

Contributor

CaptainN commented May 31, 2017

After upgrading to meteor 1.5 (from 1.5-rc.7), my app had been running with meteor-tool/1.4.x.x (as revealed by the path in my terminal title bar) - is that a problem? It would run meteor-tool/1.5.0.xxxx when doing an update.

I start meteor with meteor npm start which invokes the script "start": "meteor --settings settings-development.json" from package.json

I fixed it by uninstalling and reinstalling meteor from scratch.

@AayushShrestha

This comment has been minimized.

Show comment
Hide comment
@AayushShrestha

AayushShrestha Dec 4, 2017

@benjamn This should be "expiresIn" instead of "expiresAt"

@benjamn This should be "expiresIn" instead of "expiresAt"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment