Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Webpack path resolving for namespaced imports within core #55

Open
davwheat opened this issue Jul 30, 2021 · 0 comments
Open

Use Webpack path resolving for namespaced imports within core #55

davwheat opened this issue Jul 30, 2021 · 0 comments

Comments

@davwheat
Copy link
Member

davwheat commented Jul 30, 2021

Feature Request

Is your feature request related to a problem? Please describe.

Right now, core uses loads of relative imports, consisting of paths such as ../../common/components/Button. These are long and result in less readable import paths. This isn't an issue, per sé, but it's more about improving the developer experience so we don't need to try and count how many directories up we need to go when writing imports.

Once we end up with large chains of imports, relative paths get more complicated, as we begin combining imports within the file's namespace (e.g. admin imports in an admin file) as well as common imports:

import DashboardWidget from './DashboardWidget';
import listItems from '../../common/helpers/listItems';
import ItemList from '../../common/utils/ItemList';
import Dropdown from '../../common/components/Dropdown';
import Button from '../../common/components/Button';
import LoadingModal from './LoadingModal';

Describe the solution you'd like

Webpack (and Typescript) offer path resolution. We currently use this in our tsconfig for extensions to tell them that imports to flarum/* are typed by dist-typings in their vendor directory.

We can also use this within core itself to help us with resolving imports to each of our current namespaces. The macro-standard that most projects seem to take is prefixing resolved paths with a special character, such as @, to indicate that they're not real modules (...even though @ can be present in real module names).

Examples

Old Suggested
../../common/components/Button @common/components/Button
../../../forum/app @forum/app

If the idea of @common, @forum and @admin don't tickle our fancy, we can also choose to use the same paths that extensions use within core for simplicity:

Old Suggested 2
../../common/components/Button flarum/common/components/Button
../../../forum/app flarum/forum/app

Taking our example from earlier:

import DashboardWidget from '@admin/components/DashboardWidget';
import listItems from '@common/helpers/listItems';
import ItemList from '@common/utils/ItemList';
import Dropdown from '@common/components/Dropdown';
import Button from '@common/components/Button';
import LoadingModal from '@admin/components/LoadingModal';

or...

import DashboardWidget from 'flarum/admin/components/DashboardWidget';
import listItems from 'flarum/common/helpers/listItems';
import ItemList from 'flarum/common/utils/ItemList';
import Dropdown from 'flarum/common/components/Dropdown';
import Button from 'flarum/common/components/Button';
import LoadingModal from 'flarum/admin/components/LoadingModal';
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant