Can't run locally for modifications about astexplorer HOT 11 CLOSED

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?

from astexplorer.

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...

from astexplorer.

have you seen this before?

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

from astexplorer.

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?

from astexplorer.

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.

from astexplorer.

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?

from astexplorer.

I'll check if using webpack would solve this.

from astexplorer.

@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 :(

from astexplorer.

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

from astexplorer.

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!

from astexplorer.

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.

from astexplorer.