6.8.0 causes Uncaught ReferenceError: require is not defined errors

[EvHaus]

My project's babylon package upgraded to 6.8.0 today as a result of a devDependency of babel-core. As a result, some stuff broke.

Specifically in my app I do some dynamic babel parsing (ala. repl). So I import babel directly like this:

import preset_es2015 from 'babel-preset-es2015';
import preset_react from 'babel-preset-react';
import preset_stage0 from 'babel-preset-stage-0';
import {transform} from 'babel-core';

It seems this no longer works with 6.8.0 and results in the following error stack:

The top-most item in the stack is babylon/lib/index.js failing on var _parser = require("./parser");

Rolling back to babylon@6.7.0 makes the errors go away.

I looked through the 6.8.0 CHANGELOG for both babylon and babel-core and can't see any reason why this would be happening. Can you please advise?

[hzoo]

Sorry, looking into it. It seems like we missed a step when moving babylon out of the main repo. (This was the first release out of it)

[sebmck]

Seems to be resolved?

[EvHaus]

@kittens This is still an issue for me in babylon@latest (6.8.1).

[hzoo]

Oh is this just because of default exports? We just need to add the add-module-exports plugin like I did in babel

Made #52

[brzpegasus]

Does this have to do with the fact that the minor version bump from babylon@6.7.0 to babylon@6.8.0 is accompanied by a major version bump of babel-runtime from 5.0.0 to 6.0.0? We are seeing errors in ember-suave as well as a result of upgrading babylon.

[loganfsmyth]

Sorry, I raised this on our internal chat when you originally filed this, but it appears I forgot to comment here, woops!

This is because we accidentally didn't transition over our scripts to bundle Babylon together into a single file. Pre-6.8.x, Babylon was processed with browserify before being published, which meant that it didn't actually have any require calls in it, but also meant that Webpack complains when trying to package it.

You likely have noParse: /babylon/ in your webpack config to tell webpack to not complain, but that also means that webpack will not walk through the file looking for require calls. Then we released 6.8 without the browserify bundling, which means we started having require calls again.

We either need to add the browserify bundling back in, or if we decide we don't want that, you should remove noParse from your config. I wouldn't recommend doing that until we make a call on whether to add Browserify again on our end though.

[sebmck]

We shouldn't add back browserify since there's no module deduping so there's always an extra version of core-js.

[loganfsmyth]

Maybe @jmm can chime in, I was under the impression there was a way to bundle your local files without bundling node_modules, but I may be wrong.

[EvHaus]

@loganfsmyth Just wanted to confirm that I do indeed have this in my webpack :)

// Hides some "This seems to be a pre-built javascript file." warnings
// caused as a result of importing the Babel polyfills for the
// live code editing feature
noParse: /node_modules[\/\\]babylon/

[jmm]

@loganfsmyth @kittens I can check this out to see what we can do with Browserify to avoid bundling duplicate modules (there are ways of excluding certain modules). But the original reason for Browserifying was to prevent people from requiring "internal" modules, right? Do people still care about that?

[danez]

We have the latest babylon running in browser bundled with webpack at my company, and don't have a problem. Though we don't have babylon flagged as noParse.

What was the initial reason to bundle babylon with browserify?

[hzoo]

I removed babel-runtime so there's no dependencies now and we can run browserify/webpack/rollup if we wanted to

[hzoo]

Shouldn't be an issue after #190 / https://github.com/babel/babylon/releases/tag/v6.13.1 since we remove requires and use rollup?

[EvHaus]

I've moved over to using babel-standalone for my needs here and that has resolved the issue. Closing.