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

[0.6] Cannot find view "node_modules\d-connection-alert" #403

Open
icaliman opened this Issue Apr 8, 2014 · 6 comments

Comments

Projects
None yet
4 participants
@icaliman
Contributor

icaliman commented Apr 8, 2014

I am getting this error in browser in all derby-examples that use d-connection-alert component:

Uncaught Error: Cannot find view "node_modules\d-connection-alert" in
  Page
  Title
  Styles
  Head
  Body
  todo
  F:\Programare\Node.JS\derby-0.6\derby-examples\todos
  d-connection-alert
 components.js:175

If I run todos example, in the generated script from http://localhost:3000/derby/todos I see that __dirname for components is in windows path format.
Here you can see some code from http://localhost:3000/derby/todos:

...
(function (__dirname){
module.exports = ConnectionAlert;
function ConnectionAlert() {}
ConnectionAlert.prototype.view = __dirname;
...
}).call(this,"/node_modules\\d-connection-alert")
...

Because __dirname is in windows format here path module returns incorrect basename.
For "/node_modules\d-connection-alert" it returns "node_modules\d-connection-alert" instead of "d-connection-alert".

When I change in debugger __dirname to be /node_modules/d-connection-alert path module returns d-connection-alert as basename and it works as expected.

@icaliman icaliman changed the title from [0.6] Incorect "__dirname" for components in the browser to [0.6] __dirname is incorrectly formatted on the client side Apr 8, 2014

@icaliman icaliman closed this Apr 9, 2014

@icaliman icaliman changed the title from [0.6] __dirname is incorrectly formatted on the client side to [0.6] Cannot find view "node_modules\d-connection-alert" Apr 9, 2014

@icaliman

This comment has been minimized.

Show comment
Hide comment
@icaliman

icaliman Apr 9, 2014

Contributor

Maybe this issue happens only on windows. @nateps can you check this please?

Contributor

icaliman commented Apr 9, 2014

Maybe this issue happens only on windows. @nateps can you check this please?

@icaliman icaliman reopened this Apr 9, 2014

@nateps

This comment has been minimized.

Show comment
Hide comment
@nateps

nateps Apr 9, 2014

Contributor

I'm sure its Windows only given the slashes.

Contributor

nateps commented Apr 9, 2014

I'm sure its Windows only given the slashes.

@icaliman

This comment has been minimized.

Show comment
Hide comment
@icaliman

icaliman May 28, 2014

Contributor

Adding 'name' attribute to all components is fixing this issue on windows.

But in my project I am using components like d-bootstrap that don't have 'name' attribute setted.

Contributor

icaliman commented May 28, 2014

Adding 'name' attribute to all components is fixing this issue on windows.

But in my project I am using components like d-bootstrap that don't have 'name' attribute setted.

@icaliman

This comment has been minimized.

Show comment
Hide comment
@icaliman

icaliman Jul 7, 2014

Contributor

Some updates on this issue?

I created a patch for windows users
https://www.npmjs.org/package/derby-patch

Contributor

icaliman commented Jul 7, 2014

Some updates on this issue?

I created a patch for windows users
https://www.npmjs.org/package/derby-patch

@cjblomqvist

This comment has been minimized.

Show comment
Hide comment
@cjblomqvist

cjblomqvist Dec 30, 2014

The original problem of this issue lies within the path module which browserify uses, which is hard-coded to non-windows only, because browserify has currently no good default solution for detecting the original environment. We had a solution but it does not really work so well after some more testing. I'll get back if we find a better solution.

The original problem of this issue lies within the path module which browserify uses, which is hard-coded to non-windows only, because browserify has currently no good default solution for detecting the original environment. We had a solution but it does not really work so well after some more testing. I'll get back if we find a better solution.

@zag2art

This comment has been minimized.

Show comment
Hide comment
@zag2art

zag2art Dec 30, 2014

Member

Will be waiting!

Member

zag2art commented Dec 30, 2014

Will be waiting!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment