-
-
Notifications
You must be signed in to change notification settings - Fork 26.8k
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
create-react-app should allow TypeScript imports outside src
#8785
Comments
Hi @bluenote10 |
I know that it is possible, as I have documented in the link. However the process to get there is out of proportion. The area of working against the CRA defaults is quite a mess for a newbie, and because the settings of CRA are hidden, documentation is poor. I worked on the solution for 3 evenings, roughly 3 hours each. Isn't it crazy to be stuck for such a long time on a basic configuration problem, not doing anything productive? I thought the idea of CRA was to get people going quickly. After spending 9 hours on solving a problem that seems to be a basic requirement and facing limitations that have no clear motivation at all, I thought I report my experience. |
+1, typescript should be enabled for outside the src folder by default. Or at least there has to be a way to import typescript dependencies by relative path in package.json - which seems to be currently impossible to do, without ejecting and pretty much losing any benefit of cra.
I'd think this should work even if the mycore dependency above is in written in typescript |
I agree that code sharing should be encouraged and easier as long as the import does not leave the repository. |
+1, I would say this is one of the deal-breakers for us, we have lots of shared components and utility functions/classes, and sharing them across multiple CRA projects has been more than painful. Ofc we can hack our way through this, using things like |
just to document react-app-rewired/customize-cra workaround for anyone looking for a solution:
with these changes, CRA starts detecting and building typescript codebases outside of the project |
@ttaranov react-app-rewired stopped supporting CRA at version 2.0 and now we are at 4.0, so isn't this a very fragile setup? |
@bluenote10 I had facing this problem lately, and I agree with you totally. |
Is it explained somewhere why the restriction on not importing things from outside src/ exists? What do the CRA maintainers recommend for sharing e.g. TypeScript files with the frontend? |
@erjiang Because Original motivation is here
quote from #2189 |
I have a repo with structure like: -- frontend-app1 With above setup I want to work on both apps with shared logics inside domain directory. It would be hard to rebuild this logic and setup it as package, then install from package manager in both apps - just to have it in node_modules directory. Is there any chance that this option will be at least considered? |
It should be noted that this TypeScript issue is a bit of a showstopper for enabling imports outside src. Basically TypeScript has a bug (or design limitation?) that allows it to import from a "foreign" Ideally that TypeScript issue should be fixed first to allow for sensible cross-folder imports. |
That actually sounds like a good argument. However, there could be an easier way to tell TS that I eventually want to hurt myself and import something outside |
Hi there, Just add the following lines into the config-override at the root CRA level, and everything should be fine
P.S: Do not forget to change scripts in package.json to react-app-rewired. |
@ttaranov response is still the best solution I found so far. Thank you |
I ended up side stepping this issue by syncing sources from a shared directory into one inside src using lsyncd. It's easiest if your shared directory is an npm package, Webpack will resolve dependencies from the nearest node_modules so the react app doesn't need to reference internal dependencies of the shared package. |
I have the exact same situation as @sculpt0r described above. I have had to make some shared npm packages to share things across different CRA apps, but I would much rather be able to share components/logic across different CRA apps in a mono-repo. Please, please--for all the reasons described above-- allow us to import files outside of source.
If we uses the ...
plugins: [
// Prevents users from importing files from outside of src/ (or node_modules/).
// This often causes confusion because we only process files within src/ with babel.
// To fix this, we prevent you from importing files out of src/ -- if you'd like to,
// please link the files into your node_modules/ and let module-resolution kick in.
// Make sure your source files are compiled, as they will not be processed in any way.
new ModuleScopePlugin(paths.appSrc, [
paths.appPackageJson,
reactRefreshRuntimeEntry,
reactRefreshWebpackPluginRuntimeEntry,
babelRuntimeEntry,
babelRuntimeEntryHelpers,
babelRuntimeRegenerator,
]),
],
... There's no easy change that can be made here either. Sadly this is a real dealbreaker and hampers the workflows for alot of people. For such a common need as this it would be great to have a more workable solution available. 😢 |
@lingdocs Only removing that part will not solve the issue as I am struggling a few days to come up with a solution. |
no its not working for me |
import { |
Please note that this will copy your shared directory to node_modules, so changes to this directory are not reflected. We ended up not using this solution. |
This sounds like a joke. What if we want to reference a file that doesn't need any babel processing? Also, it sounds dumb to use eject solution only for this. |
I am also encountering similar issues to others in the threads, and the hacky solutions proposed did not work for me. This is definitely an important ask |
I am currently working on an app using Electron and React. I am in a situation right now where I have several enums and other data/functions that need to be shared between the src and electron folders, but this is not possible. This has led to me copy pasting the same data/functions to separate directories and having to update both when a change is made. Horrendous. |
+1. |
I just tried doing a whole project in Vite and it does this perfectly among other things, if you want a lightweight OOTB-usable framework for React that has hot reload and produces static assets I think it's the reasonable choice. |
When is this change going to be made to allow outside of /src? Any ETA? |
Hi guys I don't know if this might be helpful to you, but I published this npm package so I could "inject" the code inside a CRA project rather than eject itself.
|
This reply helped a lot, seems the world is moving away from create react app, this works by default in Vite |
Francois,
Thank you for this feedback. Yes unfortunately CRA is not what it used to
be and we found it very issue prone so now we do suggest Vite.
I'll pass this info alone to engineering. Thank you!
…On Mon, Jul 31, 2023 at 10:58 AM Francois ***@***.***> wrote:
How can it be done with craco ?
—
Reply to this email directly, view it on GitHub
<#8785 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ATIMPTB3QPDCZFOD2KEEAEDXS7B2NANCNFSM4MA5O63A>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
I am having similar issue, but it occurs only when I build application from Linux container. When I build from my local widow machine it works fine. is it some environment issue? Also how does it allow us to import controls from node_modules folder which is outside SRC directory as well. |
Is your proposal related to a problem?
Code reuse is a good thing. It is not uncommon that a backend and a frontend can use the same code, and live in the same repository. The need for sharing code is particularly strong with TypeScript type definitions, because developers on the backend and the frontend want to make sure that they are building against a common types.
Describe the solution you'd like
I don't know the CRA internals, but maybe one of the following:
baseUrl
to point outside.
to enable absolute imports like `import * as foo from 'common/foo``.src
likeimport * as foo from '../../common/foo'
.Describe alternatives you've considered
There are work-arounds using a combination of third-party cra-patching libraries. They are tedious to setup though (I worked 3 evenings on coming up with a solution), potentially fragile, and the use case seems so fundamental that I'm very surprised that it is not to supported out-of-the-box.
The text was updated successfully, but these errors were encountered: