You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
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-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
../../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:../../common/components/Button
flarum/common/components/Button
../../../forum/app
flarum/forum/app
Taking our example from earlier:
or...
The text was updated successfully, but these errors were encountered: