Support importing files from outside of the root folder

[shaneosullivan]

Is this a bug report?

No

The current stance of CRA to disallow importing files from outside the root folder of an app forces the most involved users, those with multiple projects, to jump through hoops that should be unnecessary in order to share code, both components and utils.

Current options are

• Symlink folders. This apparently is flakey (Symlink behaviour #3547) and can potentially cause issues running on Windows
• Copy the source files into multiple locations every time they are modified, and check in many copies of hundreds of files. This is our current approach at my company as it works well in CI, but results in human error when newbs edit the copied file rather than the original, and is messy with hundreds of unnecessary copies existing in the codebase.

If we can allow CRA project to just act as another non-special folder in a larger mono-repo, and import files from outside it's root folder, it would greatly improve the experience of working with many CRA projects while keeping all the benefits of not ejecting.

[bugzpodder]

My best experience is w/ using yarn workspaces.

[miraage]

It was made intentionally to prevent users from importing something wrong.
You can either use workspaces or eject and remove ModuleScopePlugin from the resolve.plugins option in both dev/prod configuration.

[audiolion]

I personally am having one hell of a time getting CRA to work with yarn workspaces.

With the following setup:

packages/graphql - all my graphql fragments, queries, mutations, subscriptions
packages/controllers - shared JSX code between web/native
packages/web - cra 2.0
packages/native - react native

CRA says, oh you want to do graphql just use babel-plugin-macros with graphql.macro except that library only supports relative path imports, not an import like @monorepo/graphql/queries/user.graphql

CRA also doesn't support monorepo so I have to setup webpack, parcel, or something similar to bundle my JSX, but also to run the babel macros and have it all compiled so react can import it. It just seems to defeat the purpose of CRA, I want my imported code to run under the same config options that CRA has and not have to duplicate it all and have a separate bundler running in packages/controllers.

If I don't use a monorepo to share my code, then I am publishing a private npm package every time I make a change.

[shaneosullivan]

@miraage I know it was intentional, and there were reasons. I'd like to see those reasons revisited given the inordinate amount of hacks it requires to work with multiple projects, which I presume was not fully appreciated at the time the decision was made.

A config option to let projects opt out of this feature would be sufficient, where the majority of people still get the same behavior but power users do not have arbitrary barriers to good hygiene put in their way

[eddiemonge]

If I don't use a monorepo to share my code, then I am publishing a private npm package every time I make a change.

You don't have to publish the package. In your package.json just specify the local path to module

[audiolion]

You don't have to publish the package. In your package.json just specify the local path to module

so I currently have a package.json everywhere, but because these are located outside the cra folder root, they aren't compiled, so I am currently running babel src --watch --out-dir dist in my other packages and using graphql-tag.macro to compile graphql

[shaneosullivan]

@eddiemonge a few points about multiple repos:
1 - A small portion of our overall code base should not dictate how we choose to store and share code. We use monorepos for very good reasons, and CRA gets in the way of that. If it forces us to choose between our monorepo and ejecting, we'll eject, but we really don't want to.
2 - Using multiple repos just for CRA apps makes it work differently to every other piece of code we use. It works differently in CI, each new engineer needs to know it's a special case etc. None of this is necessary.
3 - This current limitation is a design choice. It can be removed at any time with minimal to no issues being caused. This decision should be discussed at length by the React team based on feedback from the community. Discussing the various workarounds is not overly helpful - they're all hacks around a limitation that can be removed, thereby removing the need for bad code organization

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[shaneosullivan]

OK, here's some recent activity. This feature still makes sense and prevents clean usage of more than one CRA project per code repo. Any movement on this?

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[shaneosullivan]

OK, here's some recent activity. This feature still makes sense and prevents clean usage of more than one CRA project per code repo. Any movement on this?