Module warnings unavoidable when importing inside config dependency

[DesignByOnyx]

I have a file I use in both a config dependency and within my app:

// config dependency:
const config = require('../shared/config');

// throughout client code
import config from '~/shared/config';

This results in the "module instantiated twice" warning in a way which is unavoidable unless we abandon the use of tilde/project-name in all of our project code.

[matthewp]

This is a dupe of https://github.com/stealjs/steal/issues/1285. Will be fixed in the next patch release most likely.

[justinbmeyer]

I think this is a different issue. Can we reopen and discuss?

Sent from my iPhone

On Nov 8, 2017, at 6:04 PM, Matthew Phillips [email protected] wrote:

Closed #1298.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[justinbmeyer]

To be more specific, we should be warning about this case I think.

2. He has a file that he loads as a config dep and a normal dep. @matthew think it's possible to have a no-npm-resolution:path/to/module type thing?

[matthewp]

We can discuss but this still sounds like the same issue. I'm not sure what feature you are requesting. But I don't think people should have to be aware of some new syntax to avoid false-positive warning messages. Better just to change the log-level and turn on more verbose logging if you want to see these messages.

[justinbmeyer]

But I don't think people should have to be aware of some new syntax to avoid false-positive warning messages

This isn't false positive. With config dependencies, if you import node_modules/foo/bar, the module name is node_modules/foo/bar.

After npm plugin has loaded, you should import foo/bar.

Another way to fix this would be to support post-npm config dependencies.

[matthewp]

This warning is probably not visible now.

[frank-dspeed]

@matthewp what do you think about justins suggestion i mean making this even is essential as this is in other coding situations a standard case to have different paths that result in the same static path if we work with more big code bases and plug ins to modules coded by different coders.

[frank-dspeed]

@justinbmeyer @matthewp i am also suggesting implementing and using this hooks https://nodejs.org/api/esm.html#esm_resolve_hook this is the new nativ node way to handle multiple module formarts and path related stuff as also dynamic loading