It doesn’t. If you’d like, this screeenshot shows all of the errors in console that it’s giving me, dunno if it’ll help or not.
Ok I have a few things I need you to check
- If you view-source, can you see
/packages/gadicc_modules-runtime-hot.js
in the list? - Assuming you do, can you click on the link for the “regular”
/packages/modules-runtime.js
(not the-hot
one), and see if the file contains (just by searching with ctrl-f) an_expose
method? - Assuming it doesn’t, can you ctrl-r on that file, and search again to see if that method exists now, and if your app works?
I’m pretty sure this is a caching issue, but could be proven wrong :>
I did just as you said, and after I refreshed (Ctrl+R) the file (/packages/modules-runtime.js
), the _expose
method appeared (it wasn’t there at first).
Assuming this means it’s a caching issue, how do I go about fixing it? Or should it be fine now? I’m guessing my browser was using the “old” version of the runtime file as opposed to the one with the new _expose
method that your package adds to it, and that was breaking things?
After doing the refreshing of that file and then refreshing (F5) the page, it seems to be okay now. The only error I seem to be getting is one that states the following:
Failed to parse SourceMap: https://mui-test-czbaker.c9users.io/packages/undefined
Exactly. It will work your side now.
As for why, yeah, we ship a replacement modules-runtime, but the browser caches these files quite heavily. I can get past it though Will have something in the next release.
Re sourcemaps, I haven’t thought about them too much, tbh. I’m assuming this doesn’t happen without ecmascript-hot installed? The ting is, if we’re causing problems with source maps, it should only affect files that are hot loaded… i.e. if you ctrl-r to reload all the new code from scratch, source maps are completely handled by Meteor.
Thank you very much for your quick reply, btw. I’ll try this out later today, I just wanted to get it working.
Give a for 2-day release cycles
New release: gadicc:ecmascript-hot@1.3.0-2
-
Support for a
client/.babelrc
andserver/.clientrc
(that we recommend
extends your root.babelrc
). See the end of the README for the new
recommendations. You should modify your.babelrc
appropriately. Amongst
other things, this allows us to use hotloading on the client without
breaking flowrouter-ssr on the server. -
Fix browser caching issues by modifying boilerplate HTML and substituting
module-runtime’s hot with module-runtime-hot’s hash. -
No need to “eagerly evaluate” replaced modules, so don’t do that.
-
Package support See README.
-
Fix problems with escaping single inverted commas (
\\'
) in hot bundle. -
Fix some further newline munging which broke scripts where the last line
had a comment.
There are quite a few changes in here so please let me know if anything wonky starts happening (and downgrade if you need to). In particular, see the note at the top about .babelrc
changes, although you will get a warning when loading your app if you forget.
Awesome to see both Meteor and hotloading progress so quickly. I’ve just been out of the loop for the last two weeks doing testing and i’ve been left behind on beta12!
New release: gadicc:ecmascript-hot@1.3.0_4
-
Crucial fix for the infinite loop affecting majority of deployments.
My sincere apologies for this slipping through. -
Now that Meteor 1.3 is out, we’re using proper versioning. You no longer
need to specify the exact version to use, just putgadicc:ecmascript-hot
in yourpackages
file and updates will arrive withmeteor update
. -
Fix
Uncaught TypeError: Cannot read property 'c' of undefined
from
first load (since last release). -
Disable (broken) sourcemap for modules-runtime.js (since last release).
-
Transform stateless components inAs this was.js
files now too.
a critical update, this potentially unstable feature has been delayed
until the next release.
hey @gadicc, awesome work on this is this 100% react-specific, or is there a possibility for it to support HMR of other projects (Angular, Vue) later on?
does this work with meteor 1.2?
Thanks :> It’s currently react-specific, but only because I’m lazy and got to cut some corners knowing it was (initially) only going to be used for react. I thought about doing a full HMR implementation like webpack does, but it’s probably too much work; however, I do plan to offer the most used part of the API, which will probably cover 90% of the cases. You can subscribe to #8 and I’ll post any updates about this there.
No, unfortunately not… it’s completely dependant on the new module system.
Today’s update survives server reloads and works better with files that aren’t client-only, e.g. for SSR. A reminder that you no longer need to specify the version number and can just meteor update
now.
New release: gadicc:ecmascript-hot@1.3.0_5
-
We now survive server code changes, so this now works for both
imports
that aren’t beneath aclient
subdirectory and
SSR code from mixed / “both” directories with shared code. (#17) -
We no longer rely on Mongo for communications, so we now require an
extra port. By default this is Meteor’s port + 2 (i.e., right after
mongo), but you can override it with theHOT_PORT
environment variable. -
Fixes the “non-stop reload” bug where changes to files in
public
(and I guess, other shared directories with lots of files) could cause
a lot of restarts. (#22)
TL;DR;
If you’re a speed freak, check out the new experimental release and report back in that issue.
Full story:
I was working on a project today, when I caught myself not hitting ctrl-S because I’d rather make one more change first than waste the extra 500 ms. I felt that if I’m still save-averse, the project is failing, so I decided to do something about it. Time is money after all, and every ms counts. So check out the experimental release and see how it affects your hot reload times.
I changed packages to use gadicc:ecmascript-hot@=1.3.1-fast.3
And now I’m getting:
$ meteor update
This project is already at Meteor 1.3, the latest release.
=> Errors while upgrading packages:
While selecting package versions:
error: Conflict: Constraint gadicc:babel-compiler-hot@=6.6.2-beta.1 is not satisfied by gadicc:babel-compiler-hot 6.5.2_6.
Constraints on package "gadicc:babel-compiler-hot":
* gadicc:babel-compiler-hot@=6.6.2-beta.1 <- gadicc:ecmascript-hot 1.3.1-fast.3
Conflict: Constraint modules@0.5.2 is not satisfied by modules 0.5.1.
Constraints on package "modules":
* modules@=0.5.1 <- top level
* modules@0.5.1 <- ecmascript 0.4.1 <- allow-deny 1.0.2 <- mongo 1.1.5
* modules@0.5.1 <- ecmascript 0.4.1 <- mongo 1.1.5
* modules@0.5.1 <- jquery 1.11.6
* modules@0.5.1 <- ecmascript-runtime 0.2.8 <- ecmascript 0.4.1 <- allow-deny 1.0.2 <- mongo 1.1.5
* modules@0.5.1 <- ecmascript-runtime 0.2.8 <- ecmascript 0.4.1 <- mongo 1.1.5
* modules@0.5.1 <- ecmascript-runtime 0.2.8 <- gadicc:ecmascript-hot 1.3.1-fast.3
* modules@0.5.1 <- promise 0.6.5 <- babel-runtime 0.1.6 <- ecmascript 0.4.1 <- allow-deny 1.0.2 <- mongo 1.1.5
* modules@0.5.1 <- promise 0.6.5 <- babel-runtime 0.1.6 <- ecmascript 0.4.1 <- mongo 1.1.5
* modules@0.5.1 <- promise 0.6.5 <- babel-runtime 0.1.6 <- gadicc:ecmascript-hot 1.3.1-fast.3
* modules@0.5.1 <- promise 0.6.5 <- gadicc:ecmascript-hot 1.3.1-fast.3
* modules@0.5.1 <- babel-runtime 0.1.6 <- ecmascript 0.4.1 <- allow-deny 1.0.2 <- mongo 1.1.5
* modules@0.5.1 <- babel-runtime 0.1.6 <- ecmascript 0.4.1 <- mongo 1.1.5
* modules@0.5.1 <- babel-runtime 0.1.6 <- gadicc:ecmascript-hot 1.3.1-fast.3
* modules@0.5.1 <- geojson-utils 1.0.6 <- minimongo 1.0.12 <- allow-deny 1.0.2 <- mongo 1.1.5
* modules@0.5.1 <- geojson-utils 1.0.6 <- minimongo 1.0.12 <- mongo 1.1.5
* modules@0.5.1 <- es5-shim 4.5.8
* modules@0.5.2 <- gadicc:ecmascript-hot 1.3.1-fast.3
* modules@0.5.1-rc.4 <- gadicc:hot 0.0.15 <- gadicc:ecmascript-hot 1.3.1-fast.3
Conflict: Constraint ecmascript-runtime@0.2.9 is not satisfied by ecmascript-runtime 0.2.8.
Constraints on package "ecmascript-runtime":
* ecmascript-runtime@=0.2.8 <- top level
* ecmascript-runtime@0.2.8 <- ecmascript 0.4.1 <- allow-deny 1.0.2 <- mongo 1.1.5
* ecmascript-runtime@0.2.8 <- ecmascript 0.4.1 <- mongo 1.1.5
* ecmascript-runtime@0.2.9 <- gadicc:ecmascript-hot 1.3.1-fast.3
Conflict: Constraint babel-runtime@0.1.7 is not satisfied by babel-runtime 0.1.6.
Constraints on package "babel-runtime":
* babel-runtime@=0.1.6 <- top level
* babel-runtime@0.1.6 <- ecmascript 0.4.1 <- allow-deny 1.0.2 <- mongo 1.1.5
* babel-runtime@0.1.6 <- ecmascript 0.4.1 <- mongo 1.1.5
* babel-runtime@0.1.7 <- gadicc:ecmascript-hot 1.3.1-fast.3
Conflict: Constraint promise@0.6.6 is not satisfied by promise 0.6.5.
Constraints on package "promise":
* promise@=0.6.5 <- top level
* promise@0.6.5 <- ecmascript 0.4.1 <- allow-deny 1.0.2 <- mongo 1.1.5
* promise@0.6.5 <- ecmascript 0.4.1 <- mongo 1.1.5
* promise@0.6.5 <- ecmascript-runtime 0.2.8 <- ecmascript 0.4.1 <- allow-deny 1.0.2 <- mongo 1.1.5
* promise@0.6.5 <- ecmascript-runtime 0.2.8 <- ecmascript 0.4.1 <- mongo 1.1.5
* promise@0.6.5 <- ecmascript-runtime 0.2.8 <- gadicc:ecmascript-hot 1.3.1-fast.3
* promise@0.6.5 <- babel-runtime 0.1.6 <- ecmascript 0.4.1 <- allow-deny 1.0.2 <- mongo 1.1.5
* promise@0.6.5 <- babel-runtime 0.1.6 <- ecmascript 0.4.1 <- mongo 1.1.5
* promise@0.6.5 <- babel-runtime 0.1.6 <- gadicc:ecmascript-hot 1.3.1-fast.3
* promise@0.6.6 <- gadicc:ecmascript-hot 1.3.1-fast.3
@manuel, sory, I should have mentioned, this release is for Meteor 1.3.1. That’s not a “recommended” release by MDG yet, so you need to specify by hand: meteor update --release 1.3.1
. Then this version will work. Thanks for diving in so quick :>
Could anybody help to figure out with JS decorators or whatever it is? I’m trying to use this inside a react component:
dragulaDecorator = (componentBackingInstance) => {
};
then my babel config, inside the client folder, looks as:
"extends": "../.babelrc",
"presets": [
"stage-0"
],
"plugins": [
"transform-decorators-legacy"
],
...
And it seems that decorators work, but anything else doesn’t. All buttons are ignoring any actions, and new props do not come. It seems as stage-0 not a real good choice for meteor right now. Okay then if I change in presets stage-0
to decorators-legacy
I get the error: Missing class properties transform.
Any suggestions?
Edit: okay, I found that it has no clue with decorators, and it’s something from stage-1. What have I to do with this to start working?
Edit2: solved, it was this http://babeljs.io/docs/plugins/transform-class-properties/
Yeah the decorators one is a pain because it’s not included in any of the presets and load order is very important. Glad you figured it out. I got stage-0 and decorators working with:
{
"presets": [
"meteor",
"es2015",
"stage-0",
"react",
],
"plugins": [
"transform-decorators-legacy",
]
}
The meteor
preset here duplicates a few things but seems to be ok for now. I can’t remember why I have react
here, since Meteor adds it, I think it was for compatibility with some non-Meteor tools.
Edit: that’s obviously my project root’s .babelrc
, and I add the hotloading stuff in client/.babelrc
.
I seem to have problems on the client side and with my local packages. I’m getting hot-client.js:88 Uncaught TypeError: Cannot read property 'deprecate' of undefined
Any ideas? I can’t really test without the package because I need class properties, not sure how to debug this
Edit: Seems to be related to the iron:core package.
I’ll mention that the hotloading inside of packages is pretty new although I am using it every day. There’s an open issue on github about packages importing each other, haven’t had a chance to check that out thoroughly yet. Obviously this only affects packages which replace ecmascript with ecamscript-hot.
The undefined
there is usually a module we couldn’t find (I’ll try make the error more helpful in a future release) - although generally, this only happens once on certain changes and then you should never see it again after a reload. I’ll admit I’ve never seen If you’re seeing it all the time it’s breaking the hotloading, please open an issue on github, with, if possible, a link to your code and instructions to reproduce - possibly in #29.