Not able to import from inside the package without `src`

[Tarun Lalwani]

In your source sample, you have exported CompOne and CompTwo in index.js. And then imported it. But we don't want to do it, because all of projects directly import from inside the folders. Currently we do it using the ES5 transpiled imports. Now I am trying to evaluate moving to this using yarn workspaces.

But when I import directly from folder, the import doesn't work

import CompOne from '@project/components/CompOne';

This fails with the error

./src/App.js
Module not found: Can't resolve '@project/components/CompOne' in 'XXX/react-workspaces-playground/packages/apps/app-single-comp/src'

If I use it as below as per previous issue

import CompOne from '@project/components/src/CompOne';

It works. But our code base has used NODE_PATH=./src, and I am looking to avoid having to reintroduce src everywhere in imports

A forked version to showcase the issue

https://github.com/tarunlalwani/react-workspaces-playground

Can you please guide what needs to be done to make this work?

[leandro cavalcante]

I've been looking for some famous monorepos like babel and I think this is a behavior of npm and yarn workspaces itself.

For you to achieve desire behavior, you can:
1 - move components folder from src to packages/components root or
2 - create a index.js in the packages/components root and export each component individually.

Recommendation: @project/components doesn't have a dist or build folder so, it's unnecessary to create a src folder to separate things so the first option looks simpler

[Alistair MacDonald]

@tarunlalwani - I get why you want to do it that way. I tried for a while to make this possible. I couldn't find a good solution that didn't break existing import mechanisms. You're welcome to try.

I like what @leandrocrs is saying. We are basically bumping up into a limitation of how imports work in Node/Babel land. Using strategic index files can be helpful.

My opinion after going back and forth on this issue for about 6 months, settled on "keep it simple" and "go with the grain".

To me this means:

Use the default import behavior. If you don't want to import from src/ don't put the code in src/. The closer the code looks to the file structure, the easier it is for people to understand how it fits together (i.e: it's more declarative). Group related components together. import {x} from '@y' is every bit as good as import x from '@y/x'. Don't forget that Babel is tree-shaking your code. This means that even if your component group exported x, y, and z, your bundled code would only ever include source from {x} anyway. The only value that I can think of for wanting to import x from '@y/x' and hide the src/ is that you skip an index file, a couple of brackets, and 4 characters, but it comes at the cost of declarativity in a library that holds declarativity as one of it's core values.