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

Can't figure out a normalized module name for #125

Closed
luisvsilva opened this issue Oct 7, 2017 · 18 comments
Closed

Can't figure out a normalized module name for #125

luisvsilva opened this issue Oct 7, 2017 · 18 comments

Comments

@luisvsilva
Copy link

I'm submitting a bug report

  • Library Version:
    2.0.0-rc.5

Please tell us about your environment:

  • Operating System:
    Windows 8

  • Node Version:
    7.1.0

  • NPM Version:
    3.10.9

  • JSPM OR Webpack AND Version
    webpack 3.6.0

  • Browser:
    Chrome

  • Language:
    TypeScript 2.3.2

Current behavior:

Importing module from plugin results in:

Can't figure out a normalized module name for ./components/F7NavLeft, please call PLATFORM.moduleName()

Declaration of modules in plugin is done via:

export function configure(aurelia: FrameworkConfiguration) {
    aurelia.globalResources([
        PLATFORM.moduleName('./components/F7View'),
        PLATFORM.moduleName('./components/F7Pages'),
        PLATFORM.moduleName('./components/F7Page'),
        PLATFORM.moduleName('./components/F7Navbar'),
        PLATFORM.moduleName('./components/F7NavLeft')
    ]);
}

And in consumer the plugin is imported with:

 aurelia.use
          .basicConfiguration()
          .developmentLogging()
          .plugin(PLATFORM.moduleName('aurelia-framework7-typescript'))
        aurelia.start().then(() => {
          aurelia.setRoot()
        })

Expected/desired behavior:

Module should be imported, but it is currently failing

@luisvsilva
Copy link
Author

I have tried using:

PLATFORM.moduleName('components/F7NavLeft')

since components folder sit on the root of the project (src), so it should work, I get a different error:

Module not found: Error: Can't resolve 'components/f7-view' in 'c:\project\project-folder\dist\native-modules'

@luisvsilva
Copy link
Author

Also tried in package.json:

 "aurelia": {
    "build": {
      "resources": [
        "aurelia-framework7-typescript/components/F7NavLeft"
      ]
    }
  }

No joy :(

@pat841
Copy link

pat841 commented Oct 13, 2017

@luisvsilva Do you have a demo project?

Would you mind trying git://github.com/pat841/webpack-plugin.git#dist?

@luisvsilva
Copy link
Author

Tried that and same result, this is a repo testing my project:

https://github.com/luisvsilva/test-f7

The actual project is here:

https://github.com/radical-systems-australia/aurelia-framework7-typescript

@pat841
Copy link

pat841 commented Oct 17, 2017

@luisvsilva I was able to build successfully when I commented out:

      // new ModuleDependenciesPlugin(
      //   {
      //     "aurelia-framework7-typescript":[
      //       "components/f7-view"
      //     ]
      //   }),

From your webpack config.

@luisvsilva
Copy link
Author

Ha yes, my bad, I forgot that there while debugging.

So now it builds ok, if package is loaded via npm install.

I am still hitting the original problem if I use npm link as opposed to install.

You can replicate it by

npm rm aurelia-framework7-typescript --save
cd ../aurelia-framework7-typescript
npm link
cd ../aurelia-test-f7
npm link aurelia-framework7-typescript
npm run build

This is in windows, not sure if I am hitting a bug with symlinks on windows

@pat841
Copy link

pat841 commented Oct 18, 2017

Can I ask why you are using link? You should instead either create an alias or add a webpack resolver path pointing to your internal npm module.

@luisvsilva
Copy link
Author

I thought link was the way you can develop your module while testing it on the fly from another project.

is there a better solution for this? How would I use an alias? or a webpack resolver?

@jods4
Copy link
Contributor

jods4 commented Oct 18, 2017

Disclaimer: I was away and did not read the full thread above.

If you work with links, you must set the environement variable NODE_PRESERVE_SYMLINKS.
If you do it should work, that's how I work on stuff that's not published yet.

@luisvsilva
Copy link
Author

Is this valid for windows as well?

@jods4
Copy link
Contributor

jods4 commented Oct 27, 2017

I work on a Windows10 machine, so definitely yes.
Not sure what the equivalent on Linux or Mac would be.

@omniscient
Copy link

omniscient commented Nov 15, 2017

I think I am hitting the same issue here related to using this plugin in the context of a monorepo. I got this structure:
/root
--/packages
----/aurelia-components
----/aurelia-components-demo

inside my /aurelia-components-demo/package.json, when I reference the module on my npm repo like this:
"aurelia-components": "^1.0.28"

everything works just fine and I am able to au run --watch.

This is not that good because I want to have the demo refresh when I change the components. So what I tried to do instead of what I have above is to reference the package on disk:
"aurelia-components": "../aurelia-components"

As soon as I do this, when I au build, I get this:
Error: Can't figure out a normalized module name for ./dialog-box/dialog-box, please call PLATFORM.moduleName() somewhere to help.
at Compilation.compilation.plugin.modules (C:@git\Harmony\aurelia-components\packages\aurelia-components-demo\node_modules\aurelia-webpack-plugin\dist\PreserveModuleNamePlugin.js:44:31)
at Compilation.applyPlugins1 (C:@git\Harmony\aurelia-components\packages\aurelia-components-demo\node_modules\tapable\lib\Tapable.js:75:14)
at sealPart2 (C:@git\Harmony\aurelia-components\packages\aurelia-components-demo\node_modules\webpack\lib\Compilation.js:613:9)
at Compilation.applyPluginsAsyncSeries (C:@git\Harmony\aurelia-components\packages\aurelia-components-demo\node_modules\tapable\lib\Tapable.js:195:46)
at Compilation.seal (C:@git\Harmony\aurelia-components\packages\aurelia-components-demo\node_modules\webpack\lib\Compilation.js:596:8)
at applyPluginsParallel.err (C:@git\Harmony\aurelia-components\packages\aurelia-components-demo\node_modules\webpack\lib\Compiler.js:514:17)
at C:@git\Harmony\aurelia-components\packages\aurelia-components-demo\node_modules\tapable\lib\Tapable.js:289:11
at _addModuleChain (C:@git\Harmony\aurelia-components\packages\aurelia-components-demo\node_modules\webpack\lib\Compilation.js:498:11)
at processModuleDependencies.err (C:@git\Harmony\aurelia-components\packages\aurelia-components-demo\node_modules\webpack\lib\Compilation.js:468:14)

I saw similar problems on other threads on react, etc. Is this a limitation of webpack?

@jods4
Copy link
Contributor

jods4 commented Nov 15, 2017

Hard to say like that, this is tricky situations and I would need more details. Maybe fill a separate issue.

I'm not too familiar with au commands. I'm pretty sure raw webpack watches all files in compilation no matter where they're from... I would expect the former (working) config to actually be watchable.

@luisvsilva if this issue was caused by symlinks, did my tip above help you? can we close this?

@luisvsilva
Copy link
Author

Yes, it was, this can be closed. Thanks for your help

@Sayan751
Copy link
Member

@jods4

If you work with links, you must set the environement variable NODE_PRESERVE_SYMLINKS.

This works, Thank You 😄
Maybe add it wiki/docu? I think, this is very helpful when working in a monorepo, with something like lerna.

@jods4
Copy link
Contributor

jods4 commented Apr 16, 2018

@Sayan751 Yeah, a page about monorepo would be nice. I had a very hard time setting one up last week. It's hard :(

BTW, with Webpack 4, is NODE_PRESERVE_SYMLINKS still needed?
I think we now have a simpler solution with option resolve.symlinks: false.

@Sayan751
Copy link
Member

@jods4 resolve.symlinks: false works too 😄

BTW you can check https://github.com/Sayan751/aurelia-lerna-sample for an aurelia-lerna sample. Though I have created this to report bug/ask question, the build system works.

@jods4
Copy link
Contributor

jods4 commented Apr 23, 2018

@Sayan751 I have seen your other issue about mono-repo.

There are many pitfalls about mono-repo (some you have not mentionned yet in that other issue).
Let's try to figure out one complete setup that works well enough for mono-repos in #145.
If we succeed we can document it or make changes to the plugin to support it more easily.

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

5 participants