We Keep Coding

Instantiate an object defined in module A and use its methods in module B javascript

I'm working in a web development project.
Right now i'm using a 3rd party library to instantiate an object of that library in a file called, let's say, fileA.js
so i do:
import libraryExport from "./librarymain.js"
var object = libraryExport( ... );
export default object;
Now, in fileB.js i want to use the methods that the instantiated object has, for example:
import object from "fileA.js"
object.methodOfTheLibrary();
However, when im running this in my browser console i always get "methodOfTheLibrary is not a function", which means, from my point of view, that the library is not being imported properly in fileB.js
Note: I'm using webpack to bundle all of my files and everything was compiling and bundling just fine until i came with issues. I usually know my way around C++ in an advanced way but for JS i just still don't fully understand how to solve these kind of import issues.
Thank you for any help

It's generally* recommended that you avoid using an imported module directly in the body of another module. (One of your own modules, that is... as you'll see in a moment, third-party modules are generally fine to use.)
The big issue is load order. If your fileA also imports some other module, which imports another module which then imports fileB, then fileB will attempt to run and, since fileA is still trying to load dependencies, object will not actually have been instantiated yet.
You'll either need to carefully review your dependencies to look for just such a loop and then eliminate it or, if possible, restructure fileA to wrap your code in a function that can be called once the entry point has finished loading (which will guarantee that all other modules have been resolved):
// fileB.js
import object from "fileA.js"
export function init() {
object.methodOfTheLibrary();
}
// main.js
import init from "fileB.js";
init();
* "generally" meaning that there are plenty of perfectly acceptable situations where it's fine. You just have to mindful of the pitfalls and mitigate against those situations.

Javascript - Where are 'import' and 'export' statements legal?

I'm studying the new import, export feature in Javascript but was wondering, where in code will these statements be syntactically legal?
I understand something like the following won't be legal:
(function(){
import thing from './thing.js';
})();
but does this mean import is only legal at the top of the module script? Or in the global scope? E.g., what about this:
import a from './a.js';
(function(){
// ... do something with a ...
})();
import b from './b.js';
// ...
Also, does this limitation apply to export? E.g., will the following be legal?
(function(){
function internalFunc() {
// ...
}
export { internalFunc };
})();
I couldn't seem to find anything about this in the current drafts of the specification.

There is no such implementation in javascript. It's planned. But no browser implemented it yet. It's implemented in some transpilers like Webpack and Babel. There is also require in NodeJs. But not natively in javascript.
Other way to import files is using RequireJS library.
Reference: https://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/Statements/import
Edit
Answering what you asked in comments: AFAIU in the already available implementations of import and export, yes they are available in the global space, and yes import and export are hoisted.
But what isn't very clear in your comment's question is what you mean by "only available in global space". There is no such this as a close space that can't acess global space. Global space is accessible everywhere, so are import and export.

My reading of the spec is that:
module export statements should be at top level of a module
module import statements should be at top level of a module
function-style module import expressions (which return a promise for the imported items) are allowed anywhere an expression is allowed
As you say, right now it's only supported in transpilers, so I'm not sure how closely existing transpilers (Babel) follow these rules.

1) If you want just to play with import, export statements, then use it without any transpilation (with webpack) in google chrome ;)
I always use ES6 modules while I make some R&D. And then only if my temporarily work worth it, I start to think about transpilation.
Just do not forget to include scripts in such way:
<script type="module" src="index.js"></script>
2) If you need to write some nodejs script, then turn on some experimental flag to use modules - https://nodejs.org/api/esm.html#esm_enabling

Webpack bundling library causing `instanceof` to fail

I'm making a JavaScript library that can accept various plugins from an external library (cwl-svg). In this library I want to check what kind of plugin they are, so I use code along the lines of this:
import {SVGArrangePlugin} from "cwl-svg";
export default function myFunction(plugins){
for (plugin of plugins)
if (plugin instanceof SVGArrangePlugin)
doSomething();
Then, when I build my library, webpack adds the cwl-svg library to my bundle, as it should.
Now lets say the user of my library writes the following code:
import {SVGArrangePlugin} from "cwl-svg";
import func from "my-library";
func([new SVGArrangePlugin()]);
The problem is that when the user passes in a plugin to this function with new SVGArrangePlugin(), they are passing in an instance of the class from their own version of the cwl-svg library, because my library has its own bundled version. Thus, plugin instanceof SVGArrangePlugin always returns false, even though plugin is identical to an instance of that class.
How do I ensure plugin instanceof SVGArrangePlugin returns true using webpack? I considered having my library import cwl-svg using externals, but that seems to be for libraries that export themselves to the window object, when I would rather keep everything contained in my modules. Is there an obvious design decision I'm missing here?

externals is exactly what you want. It's not only useful for libraries that export something to the global object, webpack still declares it as an explicit dependency. From the docs:
The external library may be available in any of these forms:
root: The library should be available as a global variable (e.g. via a script tag).
commonjs: The library should be available as a CommonJS module.
commonjs2: Similar to the above but where the export is module.exports.default.
amd: Similar to commonjs but using AMD module system.

Babel.js using Import and Export not working

I'm trying to use import and export to create modules and it's not working.
I added https://cdnjs.cloudflare.com/ajax/libs/babel-standalone/6.24.0/babel.min.js to the index.html header and tried to import a js file and get an error message saying SyntaxError: import declarations may only appear at top level of a module. What can I possibly be doing wrong?
I know I can use require.js but rather use import and export.
HTML
script src="https://cdnjs.cloudflare.com/ajax/libs/babel-standalone/6.24.0/babel.min.js"></script
JS File
import Mymodule from './modules/mymodule';

Babel cannot perform client-side transpiling of modules, or rather it is not universally supported by browsers. In fact, unless you use a plugin, Babel will transform import into require().
If I run the following code:
<head>
<script src="https://cdnjs.cloudflare.com/ajax/libs/babel-standalone/6.24.0/babel.js"></script>
<script defer type="text/babel" data-presets="es2015">
import Mymod from './modules/module';
Mymod();
</script>
</head>
I get the following error:
Uncaught ReferenceError: require is not defined
From Babel Docs:
Compiling in the browser has a fairly limited use case, so if you are working on a production site you should be precompiling your scripts server-side. See setup build systems for more information.
Most people choose a pre-compiled module bundler like Webpack or Rollup.
If you really want to perform this client-side, use RequireJS with Babel run via a plugin, though you may need to use AMD syntax.
Native browser support for ES6 modules is still in early stages. But to my knowledge there isn't a preset/plugin available yet for Babel to tell it not to transform import/export statements.

The scripts that babel-standalone translates execute by default in global scope, so any symbols defined by them are automatically available to every other module. From that perspective, you don't need import/export statements in your modules.
However, you might be trying to maintain source files that can be used both by babel-standalone (e.g. for quick test environments, feature demonstrations, etc) and via bundlers such as webpack. In that case, you need to keep the import and export statements there for compatibility.
One way to make it work is to add extra symbols into the global scope that cause the import and export code that babel generates to have no effect (rather than causing an error as usually occurs). For example, export statements are compiled into code that looks like this:
Object.defineProperty (exports, "__esModule", {
value: true
});
exports.default = MyDefaultExportedClass;
This fails if there is no existing object called "exports". So give it one: I just give it a copy of the window object so anything interesting that gets defined is still accessible:
<script>
// this must run before any babel-compiled modules, so should probably
// be the first script in your page
window.exports = window;
import statements are translated to calls to require(). The result (or properties extracted from it) is assigned to the variable used as the identifier in the import statement. There's a little bit of complication around default imports, which are different depending on whether or not the result of require() contains the property __esModule. If it doesn't, things are easier (but then you can't support having both default and named exports in the same module ... if you need to do this, look at the code babel produces and figure out how to make it work).
So, we need a working version of require(). We can provide one by giving a static translation of module name to exported symbol/symbols. For example, in a demo page for a React component, I have the following implementation:
function require (module) {
if (module === "react") return React;
if (module === "react-dom") return ReactDOM;
}
For a module returning multiple symbols, you'd just return an object containing the symbols as properties.
This way, a statement like
`import React from "react";`
translates to code that is effectively:
`React = React;`
which is roughly what we want.

Using modules with webpack

I recently started using Webpack for frontend and came across the issue with modules.
For example, I have two modules, one uses another (to be specific its angular-bootstrap-slider and bootstrap-slider). angular-bootstrap-slider was failing to initialize due the fact that Slider function was undefined.
Now I understand that I can either export Slider globally (which I did with jquery and angular libs) or import Slider in angular-bootstrap-slider (I picked that).
I don't like both options, because global exports is one of the things I wanted to avoid using webpack and importing something in library means changing it's code.
So am I missing something or maybe there is some best practice to deal with dependencies?

What you are looking for is shimming modules.
This allows you to declare that Slider is in fact to be imported from the module bootstrap-slider:
...
plugins: [
new webpack.ProvidePlugin({
'Slider': 'bootstrap-slider'
})
]

I think you can use imports-loader: https://github.com/webpack/imports-loader
imports loader for webpack
Can be used to inject variables into the scope of a module. This is
especially useful if third-party modules are relying on global
variables like $ or this being the window object.