-
Notifications
You must be signed in to change notification settings - Fork 292
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
Library refs break when project name contains a dot #287
Comments
Hmm, I'm not sure the dot is the problem because we have a similar reference in the project containing the tests. Is your project public or can you upload a minimal project structure which can reproduce the problem? Is by any chance your directory structure similar to the one below?
Thanks for the report! |
My project isn't public, but I created a quick repo with similar structure to show the problem I'm having: https://github.com/funlambda/fable-project-ref-example If you clone it and run var _AnotherModule = require("../library-another/Library.Another/AnotherModule"); |
Thanks for taking the time to prepare the structure to reproduce the issue! It was indeed the dot :) I've released |
Works perfectly now -- thanks for the fix and the insanely fast turnaround! |
In latest Fable (0.4.4), I'm experiencing a problem when building a project that references another project. If the project being referenced has a dot in the name, then Fable is generating incorrect paths in the require calls. Before upgrading Fable, I did not have the issue.
Imagine you have a solution with three F# projects:
Library
,Library.Another
, andMain
.Main
references bothLibrary
andLibrary.Another
. Now assume the two library projects have already been compiled by Fable toout/library
andout/library-another
.Now, if you compile the
Main
project using this fableconfig.json......you will get incorrect require calls in the generated output whenever a module from the
Library.Another
project is referenced (modules referenced fromLibrary
work fine). For example:The first require call works as expected. However, the second require call has
Library.Another/
in its path for some reason, which causes a runtime error when trying to resolve the reference.A similar problem occurs when using the AMD module system.
Note: In my case, the references from
Main
to the libraries are project references made within the same solution (as opposed to an external DLL) -- not sure if that makes a difference or not.The text was updated successfully, but these errors were encountered: