import { } from ...

[edgy wadi]

I've determined that importing a function from another file, also runs any code not in any function/object (loose code). I discovered it because I have some logging on and could not understand why things were running twice.

Is this intended behavior?

Proof: Code that should not be ran (red dot). green dot is function imported in.

Code that called the function

The Logging

I do not think this is supposed to do that, but it seems it does.
Am I the only one that didn't know about this?
or is there a setting for don't run code I did not tell you to run?

[golden cliff]

intended behavior
importing a file is not just for exporting

[edgy wadi]

Then why do we need to specify what we are using from the other file?

[polar pond]

Nope, you can just do * import

[edgy wadi]

I thought import './temp.js' is when yuou want it all

I know that... but I did not do *

why can it run code that I did not implicitly import in?

[polar pond]

Which just means you can specifically call that without needing as

[golden cliff]

also if you only want the file to run you can do
import './module.js'

[edgy wadi]

I added another test where I put a import './temp.js' in there and that got pulled in by the caller of the function too... 2 files away.. so any loose code no matter where, if there is an import, it will run

[polar pond]

Correct, since js is a scripting language and not a compiled lang

[edgy wadi]

This can mess people up if they do not know this and think they are hiding code behind file walls... okay.. I can deal with it.

Thank you guys for answering

guess I need to hide in objects, lol... where they are safe

[polar pond]

Thats why its important to learn about the langauge youre using. Not all langs are the same

[edgy wadi]

I did learn it... beginner to advanced....

the erradic behavior of import was not covered... required was covered.... not import so much

[golden cliff]

import is important

[edgy wadi]

I know you can

import { obj1, obj2 } from 'file2.js'
import * as alias from 'file3.js'```I use them all.  It just does not seem logical that `import { obj1, obj2 } from 'file2.js` can take more than specified.  It takes all statements in.  Even other imports within file2.js.  It cascades.

As long as I know how something behaves, I can program around it to achieve results.

That... I am good at

[edgy wadi]

I re-read this.... https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import doesn't say anything about that situation. Do you know of a link that does say that behavior is normal?

[sonic solstice]

i can’t find anything that explicitly states it, but i can offer an example of why it’s necessary:
if you export a function which uses constants defined at the top level, those statements need to be executed for what is essentially a closure to make the vars accessible to the function

[proven river]

also when that function relies on other imported classes that are not imported on the main file where that function is being imported.

[sonic solstice]

all that to say i think that not executing top-level statements in a module would lead to worse unexpected behavior for ppl who aren’t expecting it. atp ig the solution is to place statements you don’t want to run on import inside a function or object as DW came up with

[golden cliff]

I don't see why is this confusing to be honest...
importing a file is just calling the script

[sonic solstice]

i can understand, you explicitly import a function, you expect to get the function out

[edgy wadi]

You can have things run twice that you do not need or want to run twice... I actually need to go look over a lot of code that I exposed that way.

I found this.... nothing tells you... it seems to be from experience and people explaining

[golden cliff]

let say that function use another variable that is being declared somewhere else
how will it know if it is declared if the whole code didn't run

[edgy wadi]

This is how I kinda can treat a file like a class... I export the exposed function and it can use the other stuff in the file... it is just the lose stuff that is not an assignment or an object... that well... I know now.

This is how I discovered it...
main-beta.js```js
import {main} from './main.js'

function main_beta(){ do beta stuff}
main()
main_beta()main.jsjs
export function main() {do main stuff}
main()```

I use regolith and if I run profile for beta, it uses main-beta.js as the starting script. If not beta, the manifest has main.js. And I have another filter that deletes all files -beta in the name... this way I can have stable and beta code in the same place and only one is deployed

I discovered that main() was running twice... and that lead me down this road of discovery...

I fixed it... so now only once... but I know I have previous code with stuff running twice now.

[sonic solstice]

that’s not going to be fun… 😄
i wish you good luck in finding and fixing everything

[edgy wadi]

everything is organized... long time programmer here.. just not javascript... LOL not hard... only been script api-ing for a few months now.

You would not happen to know the regex for import { main? Me and regex = oil/water

I actually kinda like refactoring... hehehe

hmmm, if I go to each file and collapse all code, i can see what is exposed (loose)

[dull needle]

I've personally never understood the behavior. People say it needs to be able to access other components in the scripts such as a declared variable at the top, but if the export is written properly that wouldn't be a concern and you could restrict calling the entire script and only what is being imported. Just my two cents on the matter.

Seems inefficient otherwise. Or pure laziness.

[proven radish]

importing intializes/runs the file

[edgy wadi]

I am fine with it, it is just that nothing tells you this. You find out the hard way. I research everything and nada. The way I used it was weird, so probably most would not run into my issue. I do know that the exported function, object, has access to what was in it's own file. That is very understandable. Just did not expect it to run the code at the bottom. But I can see now, how that would be needed. That function call at the bottom, could initiate stuff in the file that the exported procedure references.