Closed kvnneff closed 9 years ago
dominicbarnes
commented
9 years ago I'm not seeing anything wrong with a basic script. Can you include more information?
--harmony-generators flag?)client/index.js look like? (if you can't post it, can you narrow down what piece of code causes the failure?)
kvnneff
commented
9 years ago Here's what I'm using on the command line:
$ duo --stdout client/index.js > build/build.js --development
If I remove the --development option it builds without errors. I'm going to have to spend some more time with it tomorrow because it's a rather large project and there seem to be multiple points where this error occurs. Nailing it down I think will be tough.
One of the points of failure is a require statement for a local file a few levels deep in the app. If I comment out the entire file , // on every line, I get the exact same error except for this: using : stoj[SyntaxError: Unexpected number]
If I remove all the code and have simply module.exports = {} it'll build fine. If I comment out everything and have module.exports = {} being the only thing not commented out the build will fail.
If I take all of the code that's in that file and place it directly in client/index.js my build runs just fine, whether it's commented out or not. That file that is causing the failure is exactly 3 levels of requires in. If I require it from level 1 or 2 there are no errors. The same thing happens with a module I've written, staygrimm/sort-by. I can require it from anywhere in my app, grab the code from the component and export that directly from client/index.js without errors, but if I require it from this one file 3 levels deep then I get the build error.
I actually created a gist of the required file I was speaking about above: https://gist.github.com/staygrimm/ccd6347289edc5bc2f72
Most of it has been removed but that will still cause my build to fail. If I reduce it down to module.exports = {} it works fine. Pretty weird. There are a bunch of things being required before these two that I've found, though, it could be a certain sequence of things causing the failure. I'll have to experiment more tomorrow.
The other thing I've found is it builds just fine on node 0.10, but fails on both 0.11 and 0.12:
Rivers-MacBook-Pro:charts river$ nvm use 0.10
Now using node v0.10.32
Rivers-MacBook-Pro:charts river$ make build
/Applications/Xcode.app/Contents/Developer/usr/bin/make js
building : client/index.js
using : compatibility
using : stoj
built : client/index.js
# /Applications/Xcode.app/Contents/Developer/usr/bin/make css
# /Applications/Xcode.app/Contents/Developer/usr/bin/make tests
Rivers-MacBook-Pro:charts river$ nvm use 0.11
Now using node v0.11.13
Rivers-MacBook-Pro:charts river$ make build
/Applications/Xcode.app/Contents/Developer/usr/bin/make js
building : client/index.js
using : compatibility
using : stoj[SyntaxError: Unexpected token t]
error : SyntaxError: Unexpected token u
at Object.parse (native)
at Converter.toObject (/Users/river/bpt/charts/node_modules/duo/node_modules/convert-source-map/index.js:66:15)
at Sourcemap.end (/Users/river/bpt/charts/node_modules/duo/node_modules/duo-pack/lib/js/sourcemap.js:46:47)
at JS.map (/Users/river/bpt/charts/node_modules/duo/node_modules/duo-pack/lib/js/index.js:95:18)
at JS.run (/Users/river/bpt/charts/node_modules/duo/node_modules/duo-pack/lib/js/index.js:51:15)
at Pack.pack (/Users/river/bpt/charts/node_modules/duo/node_modules/duo-pack/lib/index.js:60:41)
at Duo.<anonymous> (/Users/river/bpt/charts/node_modules/duo/lib/duo.js:522:22)
at GeneratorFunctionPrototype.next (native)
at Duo.next (/Users/river/bpt/charts/node_modules/duo/node_modules/co/index.js:74:21)
at /Users/river/bpt/charts/node_modules/duo/node_modules/co/index.js:93:18
make[1]: *** [js] Error 1
make: *** [build] Error 2
Rivers-MacBook-Pro:charts river$ nvm use 0.12
Now using node v0.12.1
Rivers-MacBook-Pro:charts river$ make build
/Applications/Xcode.app/Contents/Developer/usr/bin/make js
building : client/index.js
using : compatibility
using : stoj
built : client/index.js
Assertion failed: (end <= source_len), function SliceOnto, file ../src/smalloc.cc, line 280.
# /Applications/Xcode.app/Contents/Developer/usr/bin/make css
# /Applications/Xcode.app/Contents/Developer/usr/bin/make tests
Rivers-MacBook-Pro:charts river$Yeah, I would really like your help to solve this one. It's definitely an edge-case I want to address immediately.
I did recently change the internals to duo in regards to source-maps in order to get both inline and external support. As a result, it's entirely possible a bug has been introduced. If you can trace this error down close enough so I don't need to clone your entire project, that would be immeasurably helpful!
kvnneff
commented
9 years ago Just wanted to give a heads up that it may be a few days before I have more to add. The project in question is for work otherwise I think it'd be extremely helpful if I could have you clone the entire thing because the error is proving to be really difficult to replicate.
I started to piece something together that I could share yesterday but as soon as I encountered the error in the build process I would change, say, a string that pointed to an internal url to a fake url and even just that would cause the error to vanish. Changing a variable name could mean the difference between the build failing or not. I don't even know how that's possible which makes me think I'm going crazy or overlooking something really dumb.
So I have all this work code that fails but if I change any of the wording or syntax so that I can share it then suddenly the error goes away. It's frustrating, but I'm not giving up yet.
kvnneff
commented
9 years ago I've left the company whose codebase I was working on and never ran into this issue again so I'm going to go ahead and close it.
Since upgrading to v0.10.0 my build is failing. If I revert back to v0.9.4 all is well. Here's the error I get: