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';
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:
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 bydist-typingsin 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
../../common/components/Button@common/components/Button../../../forum/app@forum/appIf the idea of
@common,@forumand@admindon't tickle our fancy, we can also choose to use the same paths that extensions use within core for simplicity:../../common/components/Buttonflarum/common/components/Button../../../forum/appflarum/forum/appTaking our example from earlier:
or...