Cannot read properties of undefined (reading 'Babel')

help
1

Hello, I wanted to report an issue we encountered while updating our project. It was very difficult for us to understand the problem. I think the error messages need to be improved. In fact, it should be specified that this devOnly flag represents a “Breaking Changes” level modification.

When we updated from version 3.2.2 to 3.4, the project ran locally, but when we tried to build it, we received the following error.

Node.js v22.22.0
Connecting to MongoDB...
Successfully connected to MongoDB
Starting app...
packages/core-runtime.js:189
            throw error;
            ^
TypeError: Cannot read properties of undefined (reading 'Babel')
    at /opt/bundle/bundle/programs/server/app/app.js:10:35
    at processNext (packages/core-runtime.js:127:30)
    at packages/core-runtime.js:138:5
    at evaluateNextModule (packages/core-runtime.js:163:14)
    at evaluateNextModule (packages/core-runtime.js:202:7)
    at runEagerModules (packages/core-runtime.js:206:3)
    at processNext (packages/core-runtime.js:128:3)
    at packages/core-runtime.js:138:5
    at runEagerModules (packages/core-runtime.js:144:12)
    ... collapsed 3 duplicate lines matching above lines ...
    at processNext (packages/core-runtime.js:128:3)
    at packages/core-runtime.js:138:5
    at evaluateNextModule (packages/core-runtime.js:163:14)
    at evaluateNextModule (packages/core-runtime.js:202:7)

However, I realized the cause of the error when the devOnly flag was added. Then I noticed that there was still an ecmascript package depending on the missing babel package. Since it’s ecmascript, a Babel import is added to app.js. This made it very difficult for us to identify the issue. I’m writing this in case others encounter the same problem. Thanks :wink:

As a simple suggestion, I think a warning should be displayed during the build process.

2

Sorry for the inconvenience with your upgrade experience. I can add a changelog note in Meteor 3.4 about the breaking changes around devOnly. Any package that depends on a devOnly package and is used in production can be affected by that. It is a very unusual scenario, and I did not expect it to happen, since removing babel from production builds did not seem risky. Usually, nobody expects babel as a transpiler to be included in production. But I see it can happen, and I see our mistake here. Large core changes have many moving parts and can lead to unexpected usages.

It’s really hard to anticipate every failing edge a change can produce, because that would require covering all possible Meteor app setups, package combinations, and production expectations. One thing we tried with Meteor 3.4 was to keep a long beta and RC period, with over 15 in total, so we could catch as many cases as possible, fix issues, and improve the docs. But even that does not remove the chance of hitting specific edge cases.

I’d like, if possible, to understand better why your production environment ended up with a Babel reference there. You mention ecmascript usage, and all Meteor apps import that package, but your report seems to be the first one we have received. Do you use Rspack or the Meteor bundler itself? Is there any other package using Babel functionality in production somehow? How did you fix it in the end? Does this happen in any small example you can share?

If I understand the exact problem better, I can understand the setup more clearly, learn from it, and better consider possible breaking changes when modifying build packages.