Skip to content
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

"includes" configuration option to add other sibling source roots? #504

Open
indigoviolet opened this issue Jun 19, 2018 · 13 comments
Open

Comments

@indigoviolet
Copy link

In our set up, we have a 'shared' directory that applies to multiple of our "apps"

something like,

root/shared
root/apps/web
root/apps/dashboard

and we use Webpack to resolve across these directories.

How would I convince import-js to look in these other locations? Would it make sense to add an includes configuration option analogous to excludes?

@trotzig
Copy link
Collaborator

trotzig commented Jun 19, 2018

and we use Webpack to resolve across these directories.

Can you explain what this means? For instance, what does an import look like from lets say root/apps/dashboard/foo.js to root/shared/bar.js?

@indigoviolet
Copy link
Author

The import looks like

import bar from 'shared/bar'

Then, somewhere in our Webpack config we have

resolve: {
  modules: ['./node_modules', './shared']
}

@trotzig
Copy link
Collaborator

trotzig commented Jun 19, 2018

Okay, cool.

Is import-js picking up exports from the shared folder and just making the imports look weird? Or are they not found at all? I'm asking because if the import statements are there but wrong, you might be able to solve this with the moduleNameFormatter configuration option: https://github.com/Galooshi/import-js#modulenameformatter

@trotzig
Copy link
Collaborator

trotzig commented Jun 19, 2018

Oh, wait. Maybe there is a package.json in each of the apps folders? That would make import-js stop there when searching for imports.

@indigoviolet
Copy link
Author

They aren't found at all, and yes, you're exactly right - there is a package.json in each of the apps folders. That's why I'd like to explicitly tell import-js about the other folders it should look in.

@trotzig
Copy link
Collaborator

trotzig commented Jun 19, 2018

I understand the issue. Having an includes config option which would allow sibling projects to be searched could be a little tricky because the file watcher we use (watchman) needs a common root. I'm not saying it's impossible though, just that it would require some work.

One workaround I can think of is to try adding symlinks inside the different apps folders. If I'm not mistaken, watchman will traverse symlinks as well.

@indigoviolet
Copy link
Author

Cool, I'll try the symlinks option and report back.

Re: watchman's requirement for a common root, is it necessary to watch the sibling projects? Could it work with the assumption that changes to the sibling directories requires a restart of the daemon?

Thanks for being so responsive!

@trotzig
Copy link
Collaborator

trotzig commented Jun 19, 2018

I guess that would work given that we document it properly with the potential addition of includes.

@indigoviolet
Copy link
Author

indigoviolet commented Jun 19, 2018

Unfortunately the symlinks approach does not seem to work.

I verified that it does work when I copy the directory instead of creating the symlink.

It doesn't look like watchman supports symlinks completely: facebook/watchman#105

However one of the suggestions in that thread (facebook/watchman#105 (comment)) which causes 'shared' to mimic a node_modules package did work for me.

@indigoviolet
Copy link
Author

indigoviolet commented Jun 19, 2018

Actually I think I was mistaken about the node_modules hack - I still had the copied folder in scope. Doing the test correctly shows that the symlink approach doesn't work at all for me.

Just documenting a version of the copying hack for future reference:

You could use https://github.com/wix/wml to do

wml add shared app/shared
wml start

Add app/shared to .gitignore

@trotzig
Copy link
Collaborator

trotzig commented Jun 20, 2018

Interesting, thanks for trying it out. I recently worked in a project which made use of Lerna (https://github.com/lerna/lerna) and import-js was able to resolve imports across sibling packages. And if I'm not mistaken, Lerna uses symlinks to "bootstrap" package dependencies.

Ninja edit: I just realize in a Lerna setup the "shared" packages are listed as dependencies in package.json. When import-js resolves imports from package dependencies, it doesn't use watchman. It simply grabs exports directly from the index file pointed out in e.g. node_modules/shared-package/package.json.

Another way to solve the problem you have could be to allow the watchman root to be overridden in config. I'd be happy to review a PR exploring a solution.

@indigoviolet
Copy link
Author

I think that one difference from the lerna setup is that our sibling root is not a package -- it isn't exporting everything from under it in an index file. Since #344 is still open, my guess is that this approach won't work without adding a burden of changing the exports.

@arggh
Copy link

arggh commented Mar 24, 2019

I was looking for a somewhat similar solution, with this kind of monorepo structure (Meteor environment):

/project
  /meteor-packages
    /package1
    /package2
    /package2
  /app1
    /packages
       /package1 *symlink -> ../../../meteor-packages/package1*
  /app2
    /packages
       /package2 *symlink -> ../../../meteor-packages/package2*
  /app3

Each app has it's own package.json and therefore it's own .importjs.js config.

To use ImportJS with the Meteor packages, I have to temporarily move the package directory over to one of the app folders, run the batch ImportJS command, then move the package directory back to /meteor-packages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants