You just use const at global scope:

const aGlobalConstant = 42;

That creates a global constant. It is not a property of the global object (because const, let, and class don't create properties on the global object), but it is a global constant accessible to all code running within that global environment.

It's probably worth noting, though, that the trend is to move away from globals, and in fact even to move away from having any code run at global scope (although top-level scripts in browsers will always have access to global scope, for compatibility).

For instance: In NodeJS, none of your code is running at global scope; everything (including the main script you run via the node command) is in a NodeJS module environment, which is not global scope. So in NodeJS, the line above wouldn't create a global, because it's scoped to the call to your module. To create a true global in NodeJS (which usually isn't necessary), you have to create a property on the global object. But how to access the global object? NodeJS calls your code with this set to an empty object (rather than the usual loose mode default where this refers to the global object), and of course there's no window in NodeJS. Answer: NodeJS provides a global available for that: global

// Define a global constant in NodeJS
Object.defineProperty(global, "aGlobalConstant", {
    value: 42
});

That's a constant because by default, properties created via Object.defineProperty are read-only.

ES2015's modules take it a step further than NodeJS: You cannot create a global at all unless the environment makes a global like NodeJS's global available to you (in which case you can do the Object.defineProperty thing). By default, per spec, there is no such global; it's just environments that define them (window on browsers, global in NodeJS, ...). And the top-level code in an ES2015's module is not run with the old default of this referring to the global object (this has the value undefined at the top-level scope of an ES2015 module), so you can't use this for it.

I understand that var is a global variable in node js and it can be accessed everywhere.

You're wrong.

var inside a function declares a variable scoped to that function.

var outside of a function declares a variable scoped to that module.

(There's an edge case, that T.J. pointed out, where if you run the code in the global context (e.g. node < yourModule.js) instead of loading it as a normal module (node yourModule.js) then it won't be treated as a module and var outside a function will create a global).

But if I put my function2 inside a help.js ; it said global_1 is undefined ; isnt it that when I import helper function, the effect is same as the above code where I paste my function2 in the same file?

No.

The variables that are "in scope" are determined by where a function is defined, not by where it is called.

As for let and const, my understanding is that they can only be accessed within a {｝　

No.

They can't be accessed outside of the block in which they are defined.

In your example they are defined outside of any explicit block, do the whole module is treated as the block for these purposes.

var a = 1;

function b () {
    var c = 2;
    let d = 3;
    
    if (a) {
        let e = 4;
        var f = 5;
        // a b c d e and f are available here
    }
    // a b c d and f are available here
    // e isn't because it is block scoped and this is outside the block
}

// a and b are available here.
// Everything else is scoped to either the function b or the block
// connected to the if statement inside it

If your variable is declared in the global scope, then it doesn't really matter if you use let or var.

These are functionally identical:

let myVar = 123;
function doStuff() {
  console.log(myVar);
}
doStuff();

var myVar = 123;
function doStuff() {
  console.log(myVar);
}
doStuff();

The difference between var and let becomes significant when you're declaring them in blocks:

if(true) {
  var foo = 1;
}
if(true) {
  let bar = 2;
}

console.log("var foo:", foo);
console.log("let bar:", bar);

As you can see, the let declaration is restricted to its wrapping block scope. The var declaration ignores block scope.

Basically,

• use let if the variable's value will change during the code
• use const if it won't and you / your team want to use const in those situations in the project you're working on; it's a matter of style

If you do use const, then it's surprising how often it turns out that the guidelines above mean you use const because you end up not needing to change a variable's value (if you're following the usual rules of keeping your functions of reasonable size and such). (Well, it surprised me, anyway...)

Using const when the variable's¹ value is not meant to change accomplishes a few things:

1. It tells others reading your code that you don't intend the value to change.

2. It gives you a nice proactive error if you change the code so it writes to that variable. (A decent IDE can flag this up proactively, but if not, you'll get the error when running the code.) You can then make an informed, intentional decision: Should you change it to let, or did you not mean to change that variable's value in the first place?

3. It gives a hint to the JavaScript engine's optimizer that you won't be changing that variable's value. While the engine can frequently work that out through code analysis, using const saves it the trouble. (Caveat: I have no idea whether this is actually useful to the JavaScript engine. It seems like it would be, but runtime code optimization is a very complicated and sometimes non-intuitive process.)

¹ Yes, it's funny to use the term "variable" to refer to something that by definition doesn't vary. :-) The specification's term is "binding," but I bet you won't hear people talking about "bindings" in everyday conversation anytime soon... So the aggregate term will probably remain "variable" except when we can specifically refer to something as a "constant."