We Keep Coding

In react why don't index.js files need to be specified on import? [duplicate]

I've noticed a few cases where I've seen something like the following:
// /reducers/reducer1.js
export default function reducer1(state = {}, action){
// etc...
}
// /reducers/reducer2.js
export default function reducer2(state = {}, action){
// etc...
}
// /reducers/index.js
import { combineReducers } from 'redux';
import reducer1 from './reducer1';
import reducer2 from './reducer2';
export default combineReducers({
reducer1,
reducer2
})
// /store.js
import masterReducer from './reducers';
export default function makeStore(){
// etc...
}
Notice the last "file" where we call import masterReducer from './reducers' - A few people seem to believe this should import the default export from the index.js file.
Is this actually part of the specification? - my interpretation/question is that this is the result of many folks using WebPack v1 which translates import statements into CommonJS-style requires statements? Or will this break in WebPack v2 with "official" import/export support?

Is this actually part of the specification?
No. How module identifiers ('./reducers' in your case) are resolved to the actual modules is left to the implementation of the module loader/bundler, it's not specificed by ES6. And it doesn't seem to be specified in CommonJs either.
This is just how node does it - when requiring a directory, it's index.js file will be used. Bundlers like browserify or webpack followed this convention (for compat reasons).

Why do npm modules, like material-ui, export es6 and es5 files?

In many npm modules I recently installed (eg. #material-ui/core) there are three ways to import the same React component:
import { AppBar } from '#material-ui/core'
import AppBar from '#material-ui/core/AppBar/AppBar'
import AppBar from '#material-ui/core/es/AppBar/AppBar'
In which scenario should I use variant 3 / es6 exported files?
If tree-shaking / dead code elimination works in webpack and the npm module. Should I rather use variant 1 (named import) instead of variant 2 (default export)?

There are two types of export:
1) Named export that is you export something like:
// exports a function declared earlier
export { myFunction };
// exports a constant
export const FOO = "foo";
if you want to import these, then syntax would be like:
import {FOO, myFunction} from './file';
2) Default export that is you export something like:
export default function() {}
you can rename your function, class to any name you want when you import, and its syntax would be like:
import myFunction from './file';
NOTE: You can have multiple named export in single file but you can not have multiple default export in single file.
For more detail check out this link: https://developer.mozilla.org/en-US/docs/web/javascript/reference/statements/export

The main difference is how that library is exporting the modules.
When you do import AppBar from '#material-ui/core/AppBar/AppBar', this means that #material-ui/core/AppBar/AppBar is exporting a single object with export default AppBar.
And you're expected to imported as you did. However you're not limited to export a single default export from your module.
For example with React exposes the main object (i.e. React which is again being exported as default) that has all the properties you may want to use. But with the import syntax from ES6, you can import a specific property/function from that module(e.g. import { Component } from 'react'; which is exported as export class Component...)
I hope that's clear!

What is the difference between these ways of importing module with Webpack?

What is the difference between importing stuff from material-ui like this
import { Paper } from '#material-ui/core'
vs. like this, which works exactly the same way in my Webpack setup:
import Paper from '#material-ui/core/Paper'
Is any of these methods of importing, costly in terms of the resulting bundle size?
Note:
I am using this in a project that was bootstrapped with Create-React-App and the Create-Reac-App that I am using uses Webpack v3.5.1

import { something } from 'test-m' implies that, test-m has a named export on it, i.e:
module.exports = {
something: 'other string'
}
or even, on the es6 syntax:
export const something = 'other string'
--
import something from 'test-m' => implies that test-m has a default exports, i.e:
module.exports = 'other string'
or with es6 syntax export default 'other string'
How this affects bundling? Well, named exports is the way to go. Why?
Named exports imports only what is necessary from each module, so by using named exports, bundlers can tree-shake the module and take out from that module only what is necessary. This process decreases by a lot the size of the final module. In comparison to default exports, bundlers would pull to the chunk the whole module, despite you using one or all features that module provides.
TL;TR: named exports === lower bundle size.

In the case of import { Paper } from '#material-ui/core' you are importing the Paper named export from #material-ui/core module which contains other named exports.
In the case of import Paper from '#material-ui/core/Paper' you are importing the default export from #material-ui/core/Paper module which contains only Paper and exports it as default.
Some libraries have this approach of exposing both the main script with named exports and the individual modules for each function. For instance, Lodash. You can do both import { find } from 'lodash' and import find from 'lodash/find'. In both cases you will get the same find function.
Regarding pros, depending on the bundler configuration and the modules system used by the library, this: import { Paper } from '#material-ui/core' may not be tree-shaked and you will end up with the whole '#material-ui/core' in your bundle.
This: import Paper from '#material-ui/core/Paper' for sure will always only add Paper to your bundled code.

The first import will import the default class export. Whereas the second import imports only the exported function/object. This is quite a common difference when importing for Jest tests in react.
Take an example of a redux connected component:
export class ReduxConnect {
render(){
return (<h1> Some component </h1>);
}
}
export const mapStateToProps = state => ({
something: state.something
});
export default connect(mapStateToProps)(ReduxConnect);
Doing import ReduxConnect will import the default import, defined at the bottom which exports the redux connected component. Whereas import {ReduxConnect, mapStateToProps} would give you the option to export objects/functions individually from the class. In this case the difference would be between importing the redux connected component vs the pure component itself.

ES6 import in for-of-loop

Is there any way to import and export multiple files using for-of-loop (or another loop) in ES6?
const moduleNames = ['NumberUtils', 'StringUtils', 'ArrayUtils', 'MyModule', 'AnotherModule', 'BaseModule']
let modules = {}
for (const moduleName of moduleNames) {
import module from './' + moduleName
modules.moduleName = module
}
export modules
Without loop I have to write:
import NumberUtils from './NumberUtils'
import StringUtils from './StringUtils'
import ArrayUtils from './ArrayUtils'
import MyModule from './MyModule'
import AnotherModule from './AnotherModule'
import BaseModule from './BaseModule'
export {
NumberUtils,
StringUtils
ArrayUtils
MyModule
AnotherModule
BaseModule
}

One of main features of ES modules is they can be statically analyzed. For this reason import statement follows strict syntax - so does export. A snippet 'without loop' is the way it has to be done.
This allows to figure out module imports and exports exactly in IDEs and tools. This is useful for tree-shaking, for instance.

I think that better and more clear way to do it is to create an index file and then import multiple components in one import.
//index.js
import PopUp from './PopUp';
import ToggleSwitch from './ToggleSwitch';
export {
PopUp,
ToggleSwitch
};
//app.js
import { PopUp, ToggleSwitch } from './components';

For multiple import files I found this solution:
const files = require.context('../myFolder', true, /(Module|Utils)\.js$/)

Difference between import X and import * as X in node.js (ES6 / Babel)?

I have a node.js library lib written in ES6 (compiled with Babel) in which I export the following submodules:
"use strict";
import * as _config from './config';
import * as _db from './db';
import * as _storage from './storage';
export var config = _config;
export var db = _db;
export var storage = _storage;
If from my main project I include the library like this
import * as lib from 'lib';
console.log(lib);
I can see the proper output and it work as expected { config: ... }. However, if I try to include the library like this:
import lib from 'lib';
console.log(lib);
it will be undefined.
Can someone explain what is happening here? Aren't the two import methods supposed to be equivalent? If not, what difference am I missing?

import * as lib from 'lib';
is asking for an object with all of the named exports of 'lib'.
export var config = _config;
export var db = _db;
export var storage = _storage;
are named exports, which is why you end up with an object like you did.
import lib from 'lib';
is asking for the default export of lib.
e.g.
export default 4;
would make lib === 4. It does not fetch the named exports. To get an object from the default export, you'd have to explicitly do
export default {
config: _config,
db: _db,
storage: _storage
};

Just adding to Logan's solution because understanding import with brackets, * and without solved a problem for me.
import * as lib from 'lib';
is the equivalent of:
import {config, db, storage} as lib from 'lib';
Where the * is similar to a wildcard that imports all of the export var from lib.
export var config;
export var db;
export var storage;
Alternatively, using:
import lib from 'lib';
Allows you to only access the default export:
// lib.js
export default storage;
Using {} also only imports specific components from the module, which reduces the footprint with bundlers like Webpack.
While:
import storage, { config, db } from './lib'
would import all modules including export default storage;
See Dan Abramov's answer:
When should I use curly braces for ES6 import?

import X from Y; is a syntax sugar.
import lib from 'lib';
is equal to
import { default as lib } from 'lib';