We Keep Coding

export is not working when try to destructure in javascript import

I have two file:
file A.js:
export default={
name:"sample"
}
file B.svelte:
import {name} from './A';
Error:
name is not export from A.js

There are two problems there:
That's now how you make the default export an object, you should remove the =.
import is not destructuring, they just have a superficial resemblance to each other. You can't destructure during an import.
I would make the export a named export:
export let name = "sample";
...which would work with your import. Changes to name by the source module will show up in the imported binding for it (imports are live bindings to the original export).
But if you don't want to do that, here's how you export an object as the default export:
export default {
name: "sample",
};
and then you have to import and destructure separately:
import obj from "./A.js";
const { name } = obj;
Note: The above is how standard JavaScript modules work according to specification. Bundlers may go beyond the spec when bundling code (for instance, may allow named import syntax when in fact you're destructuring a default exported objects), but if so, it's non-standard.

module.exports does not contain a default export

I am trying to export my theme in my react app using `module.exports =
module.exports = {
defaultFontColor: "#282828",
name: "Planswell",
primary: primary,
deemphasizedPrimary: "#e7f6ee",
secondary: "#E4A432",
danger: "#DF5F2B"...}`
in my file whatever.js, and i try to import it in another file using import whatever from "themes/whatever.js";
All was working well, but i updated Babel, and am now getting the error Attempted import error: 'themes/whatever.js' does not contain a default export (imported as 'whatever').
What changed with Babel that caused this error? And how do I fix it?

If the only export in your whatever.js is
module.exports = {mod1, mod2, ...}
Then, assuming whatever is actually a module in your file, you should have never been able to import it using
import whatever from "themes/whatever.js";
The only way that would be possible is if in your whatever.js you did:
export default whatever;
Otherwise, you will have to destructure the import like so:
import {whatever, mod1, mod2, ...} from "themes/whatever.js";
Again, all this assumes that whatever is actually a module inside your whatever.js file e.g const whatever = () => {.... You don't make that part clear.

The error you're getting should help you guide your way. When using module.exports = {...} syntax, the default export is the object.
You should try importing specific exported properties of the module such as import { someModule } from 'themes/whatever.js'. Optionally you can use
import * as whatever from 'themes/whatever.js'
// Use it
whatever.myFunction()
Babel is pretty complex tool so I would check from which version you upgraded to and then looked at the change log to see what has changed. Babel has plethora of presets and plugins so it could be any combination, sorry no simple answer here.
To me it seems like perhaps you're using some different type of module.
Maybe you are using #babel/preset-env with combination of browserslist settings and you transpile to ES6 modules?

in your whatever.js you have exporting the as an object that contain your component so you have to export it like this
import {whatever} from "themes/whatever.js";
for your example to work you have to export your component without brackets
export {whatever}

exporting React component class with one name, importing it with another name, still working. Why?

here is one file (clock.js) for my React app
class Clock extends Component { ...
...}
export default Clock;
here's another where I'm importing the Clock component
import Clock_1 from './clock/clock';
...
<Route exact path="/clock" component={Clock_1} />
as you can see, I exported it with name Clock and imported it with name Clock_1, still it is compiling and running successfully. Why?
PS: Apologies beforehand if this question sounds lame/ too simple/ stupid. I'm a beginner.

[ES6 Feature] First of all default keyword with export allows us to set Anonymous Name we want to set when we import it.
If you export it with
export const Clock,
then you have to import it strictly(ES6 way - using object destructuring syntax for named exports) with
import { Clock } from './Clock
or also can use import * as Clocks from './Clock' if you want to import all constants/variables(i.e. all named exports jammed into one object). This will make Clocks as an object with all exported variables/anything within it.
Like
Clocks = {
Clock : Clock \\ import {Clock} from './Clock',
....
}
Named exports are useful to export several values. During the import, it is mandatory to use the same name of the module as it was defined in source file.
But a default export can be imported with any name for example:
export default k = 12; // in file test.js
import m from './test' // note that we got the freedom to use import m instead of import k, because k was default export
console.log(m); // will log 12

Because you use export default. Which means that you export only that class so the name is not that relevant.
Anyway, that's why TSLint(a set of rules) says that it's forbidden to use export default.

its es6 feature, its just like giving an alias name or assigning one variable reference to another with some other name
behind the curtain it is like this when you import with some other name:
Clock_1 = Clock

ES6's export and curly braces

I saw a code got posted in a chat channel. At the very end of his code is
export {UserInformation};
There were groups saying that the syntax is wrong. Some were saying it is fine as long as the variable exists.
So which group is right? It's my first time seeing this kind of syntax too. I've never seen curly braces in export. I've only used them in import. Like this
import {method} from 'someModule';
If I was writing it, I would write it as
export default UserInformation;
I don't want to pollute my brain with wrong information. Let me know which export is correct.

The syntax is correct. This
export {UserInformation};
is shorthand for
export {UserInformation as UserInformation};
which is like doing
export const UserInformation = {};
when you define UserInformation.
It's useful to be able to export something from a module in a different place where it's defined (for readability, for instance).
In this case, you'd import UserInformation like this
import {UserInformation} from 'UserInformation.js';
Please note that export default UserInformation; is not equivalent to this. In that case, you're making UserInformation be the default module export. To import UserInformation in that case, you'd do:
import UserInformation from 'UserInformation.js';
which is shorthand for
import {default as UserInformation} from 'UserInformation.js';
This blog post is an excellent read about the topic.

What is the best way to export an object literal with ES6/2015?

Seemingly a very simple task...
export default function() {
return {
googleClientID:'xxxx'
}
}
Is it the best way to export object literal with app settings?

You can export object itself:
export default {
googleClientID:'xxxx'
};
The difference is that in your case you will get brand new object every time you call exported function. In this case you will get the same object every time. Depends on what you need.

You can simply export an object
export default { googleClientID:'xxxx' };
A default export can be a function, a class, an object or anything else. This value is to be considered as the "main" exported value since it will be the simplest to import.

#madox2 's and #void 's answer may be some kind of common misunderstanding.
I just ran into a similar problem while issuing a PR to DefinitelyTyped -- #18725. The typescript compiler complains about the generated files.
A example should be:
// ...
import zip from "./zip";
import zipObject from "./zipObject";
import zipObjectDeep from "./zipObjectDeep";
import zipWith from "./zipWith";
export default {
// ...
zip,
zipObject,
zipObjectDeep,
zipWith
};
At the first glance, i didn't think its my problem. Because i just copy the code from lodash-es. But then i can't find any simple approach to remove the errors.
So I go to the spec for answer. Wow, the spec doesn't talk about default export of an object, if I read it right.
Conclusion:
The follow is spec-respected:
export { googleClientID:'xxxx' }
Just found some more references:
https://medium.com/#timoxley/named-exports-as-the-default-export-api-670b1b554f65#a279
https://medium.com/#rauschma/note-that-default-exporting-objects-is-usually-an-anti-pattern-if-you-want-to-export-the-cf674423ac38

Exporting: not nicest, but handy when importing later.
export const ROOT = '/tmp/test'
export const EXT = '.backup'
// ... and so on
Importing: cleanest usage (and we usually import more than export).
import { ROOT, EXT } from './literals.js'
const file = ROOT + yourFileName + EXT