-
Notifications
You must be signed in to change notification settings - Fork 46.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switched from browserify to pure-cjs bundler. #1234
Conversation
Optimizations and fix for JSXTransformer build. Dropped dependency on emulation of Node.js native modules. Added deamdify step for JSXTransformer build.
I didn't really get to give this a close look last time around so a couple things:
And to bring in the table you had last time:
|
…0 for better build speed.
|
// Our own browserify-based tasks to build a single JS file build | ||
grunt.registerMultiTask('browserify', browserifyTask); | ||
// Our own commonjs-based tasks to build a single JS file build | ||
grunt.registerMultiTask('commonjs', commonjsTask); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer to call this task bundle
instead of commonjs
, because we're bundling CommonJS modules together, and bundle
is a generic term that makes sense regardless of which particular bundling tool we use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I can change that easily.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in 3f3187c.
Switched from browserify to pure-cjs bundler.
This never happened. I'll fix it. I'm going to live with this for a bit. I'm shipping 0.10 very soon so this will go out there. The file size wins are nice, but I'm actually not happy with the code that's generated. Stripping out comments from the dev build might actually be a deal breaker (especially as we encourage people to use their debugger and step through code). |
Oh and the license header says "undefined" :/ |
Let me look into license header problem. Regarding comments - we could use |
License header fixed by #1267. |
That solves part of the problem. We can't ship a file without a license header and the non-min builds don't include the apache stuff. I will fix this. BUT The other big concern and is actually a dealbreaker - That's what I meant when I said this:
|
For me changing license texts to different ones just didn't seem to be part of scope of this task.
Got it. But could you reproduce it with pure-cjs? I'm actually persisting ids exactly for saving order in https://github.com/RReverser/pure-cjs/blob/master/lib/replacerMap.js#L15-L22, ideally random reordering should never happen here (and I can't reproduce it locally, at least sizes are always the same). |
Ah, well when you removed the license header from all of the parts, we need to add it to the whole. I'm reproducing with master right now. This is a diff between 2 runs. https://gist.github.com/zpao/9625952 |
Ah, so you were talking about Apache headers... missed that in previous comment. That's right. From other point, it might be even better when you have one license comment for bundled file instead of a lot duplicates for every module function.
Nice. (not really) Should be easy to fix in dirty way, but just wondering - why is that critical for you? I mean, modules are working in the same way in any case. |
|
I'm backing this out until the problem can be resolved. Sorry |
Yeah, and that's what I'm wondering about - why is it critical to generate exactly same bundled file if it doesn't change any logic, only order of elements in array? |
Because I want my life to be simple. When I build in a branch and get a different version of a file, is it because a change was introduced? Or did my build system change the way it worked? I don't want to diff and figure that out. The other part of this (but building on simple) is ensuring that all files we distribute are identical. The file that ends up on bower, on the cdn, on cdnjs, in our starter kit, etc. If I build once and generate most of that and then happen to run the build again, I've just made a bunch of work for myself. If somebody else checks out the branch and builds him/herself, and needs to track down a line number from an error but it's different from other people's, that's annoying. So maybe that sounds silly to you but deterministic builds are currently a requirement for me. |
Now it doesn't. Don't worry, I just needed some explanations since head doesn't work that good in the evening :P Working on that right now. Could you please not to revert it for now so I wouldn't have to do one more rebase tomorrow? |
I'm shipping 0.10rc today so no. But you can do a fancy unrevert and we'll see what we can do for 0.11 |
Fixed in RReverser/react@b6519dd + RReverser/pure-cjs@5a1fe63. Are you still interested? |
Rebase of #1002.