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

Use baseUrl when checking dependencies #32

Open
neverfox opened this issue Mar 20, 2014 · 4 comments
Open

Use baseUrl when checking dependencies #32

neverfox opened this issue Mar 20, 2014 · 4 comments

Comments

@neverfox
Copy link

Currently, mimosa-require ignores Require.js' baseUrl (either the implicit default or an explicit value in config) when checking dependency strings that aren't mapped in paths, which is pretty much likely to be any non-vendor app module. So it growls errors (that aren't actually errors from Require's point of view) if you don't have main.js at the root of javascriptDir, which is the only configuration where mimosa-requires assumption lines up with Require.js' assumption about where modules can be found (assuming no other configuration is set, and who really wants to create path entries for their whole non-vendor folder structure?). Plus, since main.js often contains app code, it just feels wrong not to put it in the app folder, and right now that leads to the need to do all kinds of contortions to avoid error logs.

So it would make sense for mimosa-require, rather than to assume javascriptDir, to use baseUrl instead. Not everyone defines one, however, because the default (path of data-main) is reasonable. In that case, you could set the assumed baseUrl at the location of main.js (and perhaps add an option to override the name of the file it looks for since not everyone uses "main.js" or even data-main).

Thoughts?

@dbashford
Copy link
Owner

Let me play with it. Could you toss a simple project, a mimosa new even, that shows what your desired project structure might be?

I quickly played around with tossing main into /app and turning baseUrl to javascripts and everything hummed along from both a require.js and mimosa-require perspecive. Is that not the example you were using?

@Anachron
Copy link

Also remembers me about #31, and we shouldn't forget that you can not only load JS but also Templates and even CSS or binary files with RequireJS.

@neverfox
Copy link
Author

I've been working on one actually, trying to come up with a few different structure scenarios. I'll post it soon.

@neverfox
Copy link
Author

You're right that it does work if baseUrl is changed to javascripts, but that's to be expected. As long as RequireJS and Mimosa both think that javascripts is the base url, then things hum along. However, that seems less than ideal, because it forces the developer to adapt their RequireJS configuration (all their paths and module references) to fit Misoma's expectations, rather than the other ways around. Now the developer has to precede all reference to modules in app with app/, rather than relative to main (or some other baseUrl they might want that isn't javascriptDir).

So following something you said before, I think that if it's acceptable to Require, Mimosa shouldn't complain about it. So in this example, I have a configuration that works perfectly well from RequireJS's perspective, but generates errors for missing dependencies. I could, of course, have preceded all the module strings with ./ but I'm of the mind that relative paths in module strings isn't robust and that should be left to the require config path mappings etc.

However, it did suddenly occur to me that mimosa-require is actually making use of watch.javascriptDir in mimosa-config so I can make everything work just by changing that to whatever my Require baseUrl is. In other words, I can change Mimosa's expectations. So, I consider the problem solved unless you see some reason why that isn't an acceptable way to deal with this. For one thing, it won't watch the vendor folder in its current location, but then again, I'm not sure if vendor.javascripts effectively stops that from happening anyway.

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