I know this is a rant, but it really drives me crazy.
I just wanted to upgrade a Meteor 1.6 app to 1.10.1. Not only did this endeavour take me a whole night to accomplish - as it required a whole bunch of work-arounds for breaking changes (some documented, some not) - the app I finally ended up with is barely usable.
The initial build time after doing a meteor reset on Meteor 1.6 was 1:05 minutes. On Meteor 1.10.1, this increased to 4:50 minutes. Most of that time is being spent transpiling the application 3 times, for web.browser, web.browser.legacy and web.cordova. Each of these runs takes way longer than the whole transpilation took in Meteor 1.6. Plus, for each target platform, all of my SCSS files seem to be transpiled again, which also takes ages.
If I run the app in the browser afterwards, the Chrome inspector is behaving very weirdly. It is not really possible to select an element, because each mouse action takes seconds to perform. I have yet to find out what is causing this weird phenomenon. If I revert my app back to 1.6, everything works as expected.
I can’t help, but this is not a good developer experience at all and makes me wonder if Meteor ever gets tested against “real world applications”, especially if they are using Cordova and SCSS? This is about the 4th time now I am spending hours and hours to workaround weird upgrading effects.
I thought the exclude flag was added to resolve this issue during development, have you tried using it?
The 3 compilations is to allow producing optimized build (modern JS syntax) for modern browsers and revert to legacy when an older browser is encounter. I think eventually legacy browser support will be dropped by default.
Yes, I know. But why is a special flag required in the first place if the default now increases build times 5x? As a side-note, I am currently trying to run a minifying build, to have a look at the bundle sizes. It’s still building after more approx. 10 minutes, counting.
It’s not only the regression. It’s the sheer amount of regression. Even if I exclude the legacy arch from the build, it still takes way longer than before (1:05 => 2:35). And I have no clue why including the legacy built doubles this time to nearly 5 minutes.
Funny side-note: The problem with the Chrome inspector goes away if I execute the minified version. Still have no clue what is causing it. Also noticed that my Fontawesome fonts are not working in dev mode, while they are working fine in minified mode. Other browsers do not show this behaviour.
I think something is off, from my testing it before it didn’t regress by that much and and in fact refresh times got faster. Is this the refresh time or the initial booting time (i.e. when starting the Meteor server?)
Ah yes, I think those got slower…I’ll check the numbers again, I had them written down, but what about the refresh time? did you’ve a change to explore those?
Here are the numbers I had back when I was testing 1.8.2 betas, mind you they’ve improved by now, also this is without the exclude flags and mind you this is a very big project (with many packages etc.).
Version
After Reset (ms)
Without Reset (ms)
1.8.1
106,268 (~1.7 minutes)
33,166 ms
1.8.2 - beta-8
693,159 (~11 minutes)
106,268 ms (~ 1 min)
1.8.2 - beta-15
114,399 ms (~ 1.9 minutes)
43,967 ms
I encourage folks to try the new betas/release candidates as soon as possible to make sure any issues get addressed.
I think I now found the cause for the weird browser behaviours: most of my CSS classes have been included about a 100 times (!). This might be related to a change I had to apply to make CSS imports work again. Will further investigate.
Ok. Found out that all of the problems (including the huge build times) were actually caused by inadvertently including bootstrap SCSS files multiple times. Sorry for bothering
@waldgeist Maybe we should review what we have in place for the release process and see if we could improve it in terms of testing. I think Tiny may want to prioritize adding a QA Lead to the team (as a full time position) as Meteor’s reputation as being a stable solution is in their interest
This was a manual change I had to make due to now incompatible packages / breaking changes.
Previously, I was using {reywood:bootstrap3}. But this package references fourseven:scss@3.4.3, which cannot be used with Meteor 1.10 anymore. I had filed an issue for this back in 2017, but the package doesn’t seem to be maintained anymore. So, I dropped it and switched to npm’s Bootstrap 4.
Upgrading fourseven:scss also forced me to re-work the way my app imports the bootstrap code (as nearly on every Meteor upgrade so far). Changes in the build system make it impossible to reference SCSS files from node_modules, so you have to switch to a symbolic link approach.
While doing so, I inadvertently included the whole Bootstrap SCSS package in a global file that is referenced by nearly all of my custom packages (I intended to only include the variables file). This caused Meteor to import the whole SCSS code multiple times.
I think this happened when I was workarounding yet another issue, which occurs if multiple SCSS files contain an import with the same file name, e.g. @import "variables";. Although the files might be in different folders, Meteor always imports the file it sees first, which breaks subsequent imports. You have to switch the imports to @import "./variables" to workaround this, which I knew from previous app upgrades. Using SCSS in Meteor is really a mess.
Which reminds me that font-awesome has issues with their import paths, so instead of being able to import the index, I had to enumerate the individual files
