Develop Reference

Can't set values on `process.env` in client-side Javascript

I have a system (it happens to be Gatsby, but I don't believe that's relevant to this question) which is using webpack DefinePlugin to attach some EnvironmentVariables to the global variable: process.env
I can read this just fine.
Unfortunatley, due to weirdnesses in the app startup proces, I need have chosen to do some brief overwritting of those EnvironmentVariables after the site loads. (Not interested in discussing whether that's the best option, in the context of this question. I know there are other options; I want to know whether this is possible)
But it doesn't work :(
If I try to do it explicitly:
process.env.myVar = 'foo';
Then I get ReferenceError: invalid assignment left-hand side.
If I do it by indexer (which appears to be what dotenv does) then it doesn't error, but also doesn't work:
console.log(process.env.myVar);
process.env['myVar'] = 'foo';
console.log(process.env.myVar);
will log undefined twice.
What am I doing wrong, and how do I fix this?

The premise behind this attempted solution was flawed.
I was under the impression that webpack "made process.env.* available as an object in the browser".
It doesn't!
What it actually does is to transpile you code down into literals wherever you reference process.env. So what looks like fetch(process.env.MY_URL_VAR); isn't in fact referencing a variable, it's actually being transpiled down into fetch("http://theActualValue.com") at compile time.
That means that it's conceptually impossible to modify the values on the "process.env object", because there is not in fact an actual object, in the transpiled javascript.
This explains why the direct assignment gives a ref error (you tried to execute "someString" = "someOtherString";) but the indexer doesn't. (I assume that process.env gets compiled into some different literal, which technically supports an indexed setter)
The only solutions available would be to modify the webpack build process (not an option, though I will shortly raise a PR to make it possible :) ), use a different process for getting the Env.Vars into the frontEnd (sub-optimal for various other reasons) or to hack around with various bits of environment control that Gatsby provides to make it all kinda-sorta work (distasteful for yet other reasons).

locate corresponding JS source of code which is not optimized by V8

I try to optimize the performance of a node.js application and therefore I am analyzing the behavior of V8's JIT compiler.
When running the application via node --trace_deopt --trace_opt --code_comments --print_optcode ..., the output contains many recurring lines like the following:
[didn't find optimized code in optimized code map for 0x490a8b4aa69 <SharedFunctionInfo>]
How can I find out which javascript code corresponds to 0x490a8b4aa69?
The full output is available here.

That error message used to be around line 10200 of v8/src/objects.cc, but is no more. It basically means no optimization was currently employed for a particular trace. Possibly because it was unused, or used sufficiently infrequently. It may have likely been a Node.js library function. The address provided is in memory. You'd have to have attached a debugger to v8 and load the symbol for the SharedFunctionInfo at that location. Possibly breakpoint on the line that produces the message too.
I don't think it is that useful to know what was not optimized, as there are lots of things that don't get optimized... just take the output from --trace_opt and assume everything else isn't. It was kind of just a hint that a check was performed for optimized code, and none was there are the time. Maybe try --trace_codegen and work backwards.
This looks to be a very time consuming thing to research.
Thorsten Lorenz would be the guy to ask about this.

Tracking Down the Cause of an Error in React.js

I have an error coming up in React.js that only occurs under very specific circumstances.
When I create the error, an error prints to the JS console in Chrome, but it's not particularly semantic.
What are the best practices, tips, and tricks that you use for tracking down the offending line or function in a React.js context?
The value at line 61 doesn't seem to make a lot of sense due to the 10247 prefix – is this truly referring to line 61 or is this just junk due to a botched source map or something?
Unhandled rejection TypeError: Cannot set property 'value' of undefined
at http://localhost:4000/js/analytics.js:10247:61
at Array.forEach (native)
at http://localhost:4000/js/analytics.js:10246:16
at Array.forEach (native)
at updatePoints (http://localhost:4000/js/analytics.js:10245:29)
at module.exports.createClass.classData.componentWillReceiveProps (http://localhost:4000/js/analytics.js:10195:9)
at 43.ReactCompositeComponentMixin.updateComponent (http://localhost:4000/js/vendor.js:42736:14)
at 82.ReactPerf.measure.wrapper [as updateComponent] (http://localhost:4000/js/vendor.js:49431:21)
at 43.ReactCompositeComponentMixin.receiveComponent (http://localhost:4000/js/vendor.js:42623:10)
at Object.89.ReactReconciler.receiveComponent (http://localhost:4000/js/vendor.js:50301:22)
at Object.__REACT_INSPECTOR_RUNTIME__0_13_1.React.ReactReconciler.receiveComponent (<anonymous>:118:43)
at 43.ReactCompositeComponentMixin._updateRenderedComponent (http://localhost:4000/js/vendor.js:42865:23)
at 43.ReactCompositeComponentMixin._performComponentUpdate (http://localhost:4000/js/vendor.js:42843:10)
at 43.ReactCompositeComponentMixin.updateComponent (http://localhost:4000/js/vendor.js:42759:12)
at 82.ReactPerf.measure.wrapper [as updateComponent] (http://localhost:4000/js/vendor.js:49431:21)
at 43.ReactCompositeComponentMixin.receiveComponent (http://localhost:4000/js/vendor.js:42623:10)
Thanks in advance for your help!

Yupe, split your code into individual files and try using browserify (or webpack) with the debug flag set to true in order to map your big file with a sourcemap and ease the debugging in Chrome and friends.
Check my current stack here:
https://github.com/coma/domno?files=1

It turned out that it was an issue with Reconciliation in React.js.
React essentially uses heuristics to decide what to re-render on updates, and the react-chartjs library wasn't playing well with that.
More information can be found here: https://facebook.github.io/react/docs/reconciliation.html
The fix I used was essentially to clear the state data that is passed into chart and force an update, thus making React re-render the whole element:
this.state.countries = {
labels: []
}
this.forceUpdate()

BreezeJS RequireJS support unstable (knockout example)

As I'm trying to compile my project with breeze and requirejs for production, I'm running into multiple issues. Unrolling this, I tried starting fresh with the Knockout RequireJS example.
After I installed MVS2013Pro I was able to run the project, but not without issues:
window.breeze is defined so it has been leaked to global scope (this
should not happen with RequireJS)
Hitting F5 Refresh will crash with
Uncaught Error: Can't find breeze and/or Q (breeze savequeuing)
Uncaught TypeError: undefined is not a function (breeze dataservice)
With these errors I'm not even trying to establish my grunt requirejs (r optimizer) task. As these are the root of my problems.
Note: I'm not searching for a knockout solution, my stack actually is: MongoDataService+Breeze+SaveQueueing+RequireJS+AngularJS+Socket.IO+Cordova

window.breeze
You're right that breeze sneaks back into the browser way down at the bottom of breeze.debug.js:
if (global.window) {
global.window.breeze = breeze;
}
We don't know why we put that in the code base. No one remembers. Coming at the end as it does, it clearly isn't needed by Breeze itself.
I commented it out in preliminary testing and that seems to do the trick. The window.breeze becomes undefined in the Todo-KO-Require sample; it remains defined (properly) in samples that do not use require.js.
We don't think this would be a breaking change for anyone ... and the remedy is simple enough: define it yourself at the top of your app.
We'll probably remove these lines for the next release unless we discover a reason to do otherwise.
F5 fail?
I can't repro this at all. I suspect your are conflating your discovery that breeze is inadvertently in the global namespace with your efforts to write an Angular app that uses breeze.savequeuing.js.
Why do I think this? Because the error you describe arises when trying to use breeze.savequeuing.js in an Angular app which is explicitly disallowed in the comments (line #14) of v.1.0.4:
Depends on Breeze (which it patches) and Q.js (not for use in Angular ... yet)
You no doubt omitted Q.js from your required libraries and it all goes to custard from there.
I'm personally allergic to the "save-when-user-changes-anything" user experience that made save queuing necessary. I'm almost sorry I wrote it. But there it is.
The apparently dependence on Q.js is the reason it isn't available for Angular apps as written. It's actually pretty easy to make it Angular-ready now because we recently (quietly) made accessible the component that Breeze is using for promises
breeze.Q // returns the promises component currently used by Breeze
Therefore, you could change the one reference to Q on line #104 to
var deferredSave = breeze.Q.defer();
This should work when using breeze v.1.4.14 and later. I haven't fully tested it yet.
This change (or something like it) likely will find its way into breeze.savequeuing.js v.1.1.0 (as I just pushed a non-release version of that).

Test parse errors in intern do not include the line that describes the error

tl;dr When there is an error with a test written in intern I don't seem to get error messages that describe on which line the error occurred. I've found a workaround but its not really the ideal solution as it involves messing with code in dependent projects. Does any one have a better way / am I just doing it wrong? Thanks!
Details :
I've seen several times that when there is an issue with parsing a test written in intern (for example failing to close brackets, quotes etc.) that the actual line where the error occurred is not reported, and there is only an error like this (I've subbed in for the actual path as its a work project, but you get the gist):
SyntaxError: Unexpected identifier
at Function.vm.runInThisContext (<myproject>/node_modules/intern/node_modules/istanbul/lib/hook.js:163:16)
at <myproject>/node_modules/intern/node_modules/dojo/dojo.js:745:8
at fs.js:266:14
at Object.oncomplete (fs.js:107:15)
I poked around a little and discovered that there's an undocumented(? - its not in here) parameter for vm.runInThisContext, which if enabled actually provides details of the original error (here and here) - there's some discussion about how this will play out but if I switch dojo.js and hook.js in istanbul (if its running) to use this parameter, I get error messages like this :
<myproject>/test/publisherConfigSpec.js:16
errorCb cat = dfd.rejectOnError(function(error) {
^^^
SyntaxError: Unexpected identifier
at Function.vm.runInThisContext (<myproject>/node_modules/intern/node_modules/istanbul/lib/hook.js:163:16)
at <myproject>/node_modules/intern/node_modules/dojo/dojo.js:745:8
at fs.js:266:14
at Object.oncomplete (fs.js:107:15)
which is the output I want (or at least massively improves my chances of finding and fixing the error) but its not ideal to be messing about with the node dependencies, and it seems to me that it may be too much in flux for a pull request (see most recent update to the API) Is there an alternative way of getting useful output when there's an error parsing the test code input?
Thanks for any advice :)

The output that Node.js provides for SyntaxError is obviously not great, but we probably won’t use undocumented features (they’re undocumented for a reason!) in any official release of Intern to make it work differently. Non-syntax errors (runtime errors) will be caught and reported competently by Intern to whatever reporters you are using.
In this case, I’d advise you to use an editor that includes support for syntax checking: Komodo Edit/IDE, WebStorm, SublimeText, Eclipse, vim… if you get to the point where you are trying to run syntactically invalid code, your code editor is failing you by not telling you soon enough that you’ve made a mistake.