Open bluenote10 opened 4 years ago
Hi @bluenote10 You can disable this feature but only after eject operation of create-react-app project or use react-app-rewired package this way you do not have to eject.
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.
"dependencies": {
"@mycore-ui": "file:./../mycore-ui"
}
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. Also related to #1333 which has yet to receive any update from a CRA maintainer.
+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 react-app-rewired
or craco
, but it's not an ideal solution, and I'm curious to know why is this not supported out of the box?
just to document react-app-rewired/customize-cra workaround for anyone looking for a solution:
"dependencies": {
...
"component-ui": "file:./../component-ui",
...
},
react-app-rewired
and customize-cra and
replace script build/start/test eact-app-rewired build/start/testconfig-overrides.js
into cra project's root with
const {removeModuleScopePlugin, override, babelInclude, addWebpackAlias} = require("customize-cra");
const path = require("path");
module.exports = override( removeModuleScopePlugin(), addWebpackAlias({ ...
.. }), babelInclude([ path.resolve("src"), path.resolve("../component-ui/src") ]) );
with these changes, CRA starts detecting and building typescript codebases outside of the project `src` tree.
@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.
So I've just submit Add DISABLE_MODULE_SCOPE_PLUGIN option PR.
ModuleScopePlugin restricts import file outside /src
internally, therefore we could import from everywhere if you disable it.
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 ModuleScopePlugin
working inside webpack.
This code block is setting on webpack config file that disable include file from outside src/
.
Original motivation is here
// 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.
quote from #2189
I have a repo with structure like:
-- frontend-app1 | --frontend-app2 |
---|
--domain | ----some common logic
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" node_modules
folder. This can have nasty consequences: For instance you forget to specify dependency foo
in your package.json
in your "frontend-app1". But in "frontend-app1" you make an import to "domain" which uses foo
. If "domain" contains a node_modules
folder TypeScript may accidentally use foo
from there. I.e., you can end up in situations where the dependencies in "frontend-app1" are incomplete without realizing. Or it could cause headaches, because you assume you're using version X as specified in the local package.json
but you're rather using version Y from that foreign node_modules
.
Ideally that TypeScript issue should be fixed first to allow for sensible cross-folder imports.
For instance you forget to specify dependency foo in your package.json in your "frontend-app1". But in "frontend-app1" you make an import to "domain" which uses foo. If "domain" contains a node_modules folder TypeScript may accidentally use foo from there. I.e., you can end up in situations where the dependencies in "frontend-app1" are incomplete without realizing. Or it could cause headaches, because you assume you're using version X as specified in the local package.json but you're rather using version Y from that foreign node_modules.
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 src
directory.
@bluenote10 I had facing this problem lately, and I agree with you totally. So I've just submit Add DISABLE_MODULE_SCOPE_PLUGIN option PR. ModuleScopePlugin restricts import file outside
/src
internally, therefore we could import from everywhere if you disable it.
Hi there,
Just add the following lines into the config-override at the root CRA level, and everything should be fine
const { removeModuleScopePlugin, override } = require('customize-cra');
module.exports = override(
removeModuleScopePlugin()
);
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 eject
command and then dig into the config
directory, this is what we find:
...
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.
+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.
"dependencies": { "@mycore-ui": "file:./../mycore-ui" }
I'd think this should work even if the mycore dependency above is in written in typescript
no its not working for me
import { CommerceContextProvider, PrimeCatalogContainer, PrimeCommunityBoardList, PrimeCommunityBoardPage, PrimeInstancePage, PrimeNotificationContainer, PrimeTrainingPage, } from "@almLib/almLib"; here @almLib is declared in package.json and still shows error My goal is to access components from almLib which is outside of src
@ttaranov solution works well in 2022 for sharing a common logic folder between react and react-native projects in the same repo. Only JS and no JSX in there though - not sure if that would work. Thank you for this hack! Super valuable to stay on create-react-app.
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.
@erjiang Because
ModuleScopePlugin
working inside webpack. This code block is setting on webpack config file that disable include file from outsidesrc/
.Original motivation is here
// 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.
quote from #2189
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. Significant limitation of CRA; looking forward to a resolution.
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 solution has few issues though: 1) I lose the hot-reload of the component I want to inject. I had to build everytime I make a change (or I could work inside the lib folder for small changes, then rewrite them into the ouside folder "src"), 2) [less important] If there are any other files (such as .svg) inside the src, I had to specify inside the "build" script. The main problem was the hot-reload for me. That's why I was searching for other solutions. But maybe this solution can help someone
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.
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 https://github.com/facebook/create-react-app/issues/8785#issuecomment-1658543138, 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.