I didn't find anything on Google but I'm wondering if there's a "best practise" of structuring an ES6 project in terms of directories and module exports.
Currently I do have two different ways in mind:
Using an index.js for every module and export everything:
app.js
modules/
ModuleName/
ModuleFile.js
index.js
ModuleFile.js would look something like export class ModuleFile { }, the index.js would be simply
export * from 'ModuleFile'
This makes it possible to import files with import {ModuleFile} from 'modules/ModuleName'. Readable, but requires an index.js for every module, even if the module has just one single file.
Second approach would be without using index.js files, but that would mean import statements would become slightly redundant import {ModuleFile} from 'modules/ModuleName/ModuleFile'.
Are there any best practises on this topic?
Your approach seems fine, I don't see a problem with it. In two different projects I've worked (different companies) it was the pattern used.
You could also put the ModuleFile.js content directly in index.js:
app.js
modules/
ModuleName/
index.js
Or create a file directly for a module:
app.js
modules/
moduleName.js
In cases only a "file" is necessary. The evident problem is that changes or the growth of the module may force this structure to change. There would also be an inconsistence in terms of structure with other modules.
Related
When I create components in React, they're all in a folder called component and each component has a dedicated folder with the same name as the component itself, e.g. ../components/Input.
But a big concern is about naming files. In order to avoid having to long paths, I name the component inside the folder Index.tsx so that when I import, I'll only have ../components/Input otherwise, it would be a very ugly import path like ../components/Input/Input.
So, by naming Index.tsx, in my IDE, I end up having too much index files open and then I get lost.
So what I did was to rename all those components file with the same name as the folder Input.tsx and exporting them using named export like export const Input:React.FC<InputProps>=(props)=>{...}, then at the root of my component folder, I created one index.tsx file where I export all those components so that while importing them in my pages, I can just write import {Input} from "../components".
I like this approach, but my next concern is about tree shaking. Because I don't want to import every time the entire components library.
So with the above approach, does React handle automatically tree shaking for us?
There's a tweet about the possible issues related to re-exporting everything with index files.
If your project has a components/index.js file which re-exports all your components (and does nothing else), that’s one example.
This is bad for performance – for two reasons.
It makes code splitting ineffective.
When you do
import { Button } from './components'
you’re importing not only Button but the whole ‘./components’ file. Which means you’re bundling the whole file – with all the components it exports.
It makes bundle initialization more expensive.
Every time a browser downloads the bundle, it has to execute it – and all its modules as well. If there’re a lot of modules, or some of them do something expensive, this can take a while.
Someone else suggests configuring webpack's sideEffects option so that the tree-shaking can still optimize the bundle as much as possible.
What I'm suggesting is to create small component modules inside the components directory.
- components/
- Input/ # component module
- index.ts # exports public API
- Input.tsx # actual component implementation
- Input.test.tsx
- Input.scss
- Input.stories.tsx
- etc.
Where the index.ts only re-export the public API for this component.
// index.ts
export { Input } from './Input';
export type { InputProps } from './Input';
// etc.
So that we have non-repeating paths when importing, but the filename we're actually working with is named according to the component.
Hello guys i have a little question about importing files into a single .js file.
Which way is better (best practice), what's the scenario that is used for:
import './file;'
import { something } from './file'
import * as evertything from './file'
Because i see that 2 and 3 are the same thing but different syntax(maybe Syntactic Sugar).
All three do different things.
import './file;'
That loads the file, and does not import anything. This is useful if you want to initialize that module (or add some external dependency, e.g. a css file if you use Webpack).
import { something } from './file'
That just imports something from the file, therefore a bundler could optimize all other dependencies away. I'd always try to go with that instead of
import * as evertything from './file'
That imports everything from that module under a namespace, and therefore makes treeshaking more difficult (the bundler cannot optimize it well). I'd only use that if you need everything from that dependency, or if that dependency is loaded externally nevertheless (e.g. import * as React from "react").
I guess the following MDN documentation will make you clear about those things:
import - JavaScript|MDN
As far as I know, 1st method is used when you have only one default export. 2nd is used when you have multiple default exports but you don't want all of them to load and want only few of them. 3rd is the case when you want everything under a single object (which can be used similar to namespace in other programming languages).
I'm creating a node library that could be partially used in web browsers.
My current structure is something like:
package.json
lib/
index.js
node.js
web.js
modules/
some-function.js
some-node-function.js
some-web-function.js
...
"lib/index.js" is specified as "main" in package.json
I'm using each file inside lib/ to re-export functions from modules/ filtered by target (all/node/web)
And I would like to use it like this:
import fullLibrary from "my-library";
import {someFunction} from "my-library";
import webOnlyLibrary from "my-library/web";
import {someWebFunction} from "my-library/web";
import nodeOnlyLibrary from "my-library/node";
import {someNodeFunction} from "my-library/node";
BUT keeping index.js, node.js and web.js inside /lib!
Currently only the first two import statements work (because index.js is pointed from package.json).
I know that I could place those files in the root of the package and it would work as expected when importing, but I was wondering if there was a way to do the same while keeping the files in /lib for cleanness.
In any case, is this the recommended way to expose multiple variants of a same library from a single NPM package?
Just for anyone that is having similar questions regarding libraries structure and organization.
Back then I started working with monorepos using Lerna and Yarn Workspaces and I haven't regret it. I think this is the most efficient way to go in terms of modularity, readability, scalability and maintainability.
Specifically, the question code would be traduced into this:
import webOnlyLibrary from "#my-library/web";
import {someWebFunction} from "#my-library/web";
import nodeOnlyLibrary from "#my-library/node";
import {someNodeFunction} from "#my-library/node";
In my React and Webpack project, I have the following project structure of React components:
Component/
├── Component.jsx
├── index.jsx
└── styles.css
The index.jsx file simply imports and exports Component.jsx; the reason being that in files that require it, it allows the usage of the following:
import Component from '../Component'
as opposed to
import Component from '../Component/Component'
However this seems like it may be an unnecessary extra step which requires all new components to follow suit.
With this in mind, my question is: Can I have the best of both worlds? I want to be able to only have Component.jsx and styles.css in my directory, but not have to use the name twice in my import declaration.
Let me suggest you the following structure I personally like:
Your component tree structure (As an example every component has a different folder structure. It is up to you to keep it clean and tidy. Index.jsx in components folder just normalizes access to those components whoever needs them):
src/components/
Butter/
Butter.jsx
index.jsx
Beets/
Beets.jsx
Cabbage/
index.jsx
Meat.jsx
index.jsx
Content of components/index.jsx
export Butter from './Butter/index.jsx';
export Beets from './Beets/Beets.jsx';
export Cabbage from './Cabbage/index.jsx';
export Meat from './Meat.jsx';
Some container Borscht.jsx somewhere else in your project which uses those components
import {
Beets,
Cabbage,
} from 'src/components';
If your folder already tells you which is the component name, you don't need to put it again in the file name inside it. I use this approach.
All modern editors already solves the trouble with two equal names (ComponentA/index.jsx and ComponentB/index.jsx) for us, by adding the folder name in the tabs.
Note that this is an Vue component, but it's the same thing for React.
One option for webpack users is to install directory-named-webpack-plugin
Install, and then add the following to Webpack's config file:
var DirectoryNamedWebpackPlugin = require("directory-named-webpack-plugin");
resolve: {
plugins: [
new DirectoryNamedWebpackPlugin()
]
}
When using require("component/foo") and the path "component/foo" is resolved to a directory, Webpack will try to look for component/foo/foo.js as the entry point.
Caution: While this approach does allow webpack to resolve filenames when building and bundling, your intellisense / tooling options are a different beast altogether. Unless they also have similar functionality, you may lose Go To Definition and Intellisense support by not providing the full reference statically.
I'm currently learning react and thus es6/es7 and webpack.
Coming from a largely python background I'm annoyed by the folder sensitive path declarations for import statements, i.e. the use of ../../ in import statements. This means if I move a file to a different directory, i need to change the import statements declared in the file.
Python's import statement doesn't have this issue. I'd like to mimic that behavior
(search first a particular directory for this path, if not search this other base directory)
e.g. if i have the directory structure
myApp
components
component1.jsx
stores
store1.jsx
views
view1.jsx
node_modules
react
etc
in my view1.jsx I don't want to write
import Component1 from '../components/component1'
I want to write
import Component1 from 'components/component1'
or maybe even
import Component1 from 'myApp/components/component1'
just to make sure I don't have name collisions with some npm package I may be using.
What is the correct way of accomplishing this in webpack? Is it using alias?
I ended up following #zerkms recommendation. resolve.modulesDirectories is the way to go.
I wrote a loader to accomplish this, https://www.npmjs.com/package/future-require-loader. It will autoload a path anywhere three underscores surround a partial file path ___filename.js___. it also allows folder paths: ___folder/filename.js___. it will attempt to match the first file path that includes the string so you will want to include folders if there could be a conflict.