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
What is the new or updated feature that you are suggesting?
Currently, extending and wrapping Remix is impossible without being required to copy and overwrite some of the public & private methods. The problematic areas are:
remix config
Currently you can't get the final RemixConfig without an existing remix.config.js file. Refactoring readConfig to receive AppConfig as parameter will make it possible to get the full config programmatically.
Another part that is problematic is defineConventionalRoutes which there's no way to tell it to ignore some file that do match routeModuleExts. I would expect it to use the tsconfig's include/exclude props.
compiler
Although the build and watch methods are exported from the compiler, there are some hard coded values that makes it impossible to extend it. I suggest a refactor to also expose the final configurations that will be used in esbuild.build.
Also moving the part of getting the external from the package.json to be received as parameter will also make it easier to extend (NX for example uses a complicated calculation to get the relevant dependencies and devDependencies of a project in the monorepo)
Why should this feature be included?
A good use case for this is adding postCSS support as part of the build process instead of having different npm scripts that needs to be ran before the build itself (and also forcing you to generate build files in your src because its needed before the build)
In my specific case, I'm creating an NX plugin that adds support for remix. currently I had to "hard copy" some of remix private methods in order to override some of the configuration, im also forced to generate some files before the build itself in the source directory. this also makes it impossible for me to use the existing NX methods and build processes because NX uses webpack.
If I had the final configurations available, I can use them as part of esbuild-loader in the generated NX's webpack config (i might need to convert the plugins to be compatible with webpack so it might be wise to consider refactoring them as well & decouple them from esbuild
Just saw that version 1.1.0 added ignoredRouteFiles which is very helpful although I would still expect remix to take the tsconfig into consideration when looking for files.
What is the new or updated feature that you are suggesting?
Currently, extending and wrapping Remix is impossible without being required to copy and overwrite some of the public & private methods. The problematic areas are:
Currently you can't get the final
RemixConfig
without an existing remix.config.js file. RefactoringreadConfig
to receiveAppConfig
as parameter will make it possible to get the full config programmatically.Another part that is problematic is
defineConventionalRoutes
which there's no way to tell it to ignore some file that do matchrouteModuleExts
. I would expect it to use the tsconfig'sinclude
/exclude
props.Although the build and watch methods are exported from the compiler, there are some hard coded values that makes it impossible to extend it. I suggest a refactor to also expose the final configurations that will be used in
esbuild.build
.Also moving the part of getting the external from the package.json to be received as parameter will also make it easier to extend (NX for example uses a complicated calculation to get the relevant dependencies and devDependencies of a project in the monorepo)
Why should this feature be included?
A good use case for this is adding postCSS support as part of the build process instead of having different npm scripts that needs to be ran before the build itself (and also forcing you to generate build files in your src because its needed before the build)
In my specific case, I'm creating an NX plugin that adds support for remix. currently I had to "hard copy" some of remix private methods in order to override some of the configuration, im also forced to generate some files before the build itself in the source directory. this also makes it impossible for me to use the existing NX methods and build processes because NX uses webpack.
If I had the final configurations available, I can use them as part of esbuild-loader in the generated NX's webpack config (i might need to convert the plugins to be compatible with webpack so it might be wise to consider refactoring them as well & decouple them from esbuild
Related Issues
remix.config.js
#1209The text was updated successfully, but these errors were encountered: