Can't run locally for modifications

[RReverser]

Tried to build & run locally, but got:

TypeError: $def is not a function in browser console in following context:

loadjs.d("323",function(require,module,exports){
// 19.1.3.1 Object.assign(target, source)
var $def = require('./$.def');

$def($def.S + $def.F, 'Object', {assign: require('./$.assign')});
},{"./$.assign":210,"./$.def":219});

loadjs.d("949",function(require,module,exports){

[fkling]

Yeah, I know this issue. I'm not sure what causes it though. Using uglifyify used to solve this, I think because of dead code elimination, but maybe not anymore?

This is part of core-js. Maybe there is an issue with circular dependencies, not sure. @zloirock, have you seen this before?

[fkling]

Uh, look like I removed uglifyify from npm run watch in one of the latest commits. Will add it back, but it would still be great to find a real solution, because uglifyify slows down the build...

[zloirock]

have you seen this before?

Sure, and each time it was mistake in build configuration. For example, babel not ignored babel-runtime.

[fkling]

After looking a bit more into the generated files, it seems that $.def is required from dist/app.js, but is only defined in dist/parsers/babel.js.

Not sure why it is not defined in dist/app.js. I expected that any direct dependency of the entry file needs is also contained in it. @arian, am I doing something wrong here?

[arian]

How do you reprodue this? I just ran esprima_ast_explorer locally, using npm run watch, and the $.def module ends up in dist/app.js, just like the object.assign module.

Does updating to the latest partition-bundle help? 2.2.0 fixed some problems with deduped modules.

[fkling]

Looks like I'm already using 2.2.1. I'm using

watchify -p [partition-bundle --map partition.json --output ./ --main ./src/app] \
-o /dev/null -v

It looks like there are two ./$.def modules, one with ID 650 (this one) and one with 218 (this one), i.e. they are definitely different modules. 650 is indeed contained in dist/app.js, but 218 is not (not sure if you'd get the same numbers in your build).

The are quite a few modules in dist/app.js referencing 218, e.g.

loadjs.d("322",function(require,module,exports){
// 19.1.3.1 Object.assign(target, source)
var $def = require('./$.def');

$def($def.S + $def.F, 'Object', {assign: require('./$.assign')});
},{"./$.assign":209,"./$.def":218});

but loadjs.d("218", ...) is in dist/parsers/babel.js.

I guess reusing the same (relative) module name shouldn't matter?

[fkling]

I'll check if using webpack would solve this.

[RReverser]

@fkling Yes please! Currently scripts section using combination of browserify with some NIX-specific things so that I couldn't even contribute from own Windows machine despite this being a JS project :(

[fkling]

I switched to webpack in 89db32f. It seems to work well so far. Let me know how it works for you.

[RReverser]

Still seeing a bunch of webpack warnings on build (like, trying to require .md files somewhere and so on), but other than that, seems to build fine. Thanks!

[fkling]

Yeah, I didn't figure out where it would try to load an .md file, but everything worked for me so I didn't bother with it too much.