`yeoman server` uses cached RequireJS modules from other projects? Causes 404s. #725

Closed
thure opened this Issue Nov 18, 2012 · 15 comments

Comments

Projects
None yet
6 participants

thure commented Nov 18, 2012

Calling yeoman server on an app recently, I received a number of 404 errors for modules that don't exist and aren't even mentioned in the current project.

The dependencies generating those errors were for modules from another project which also uses RequireJS, but the modules in the current project (which, unfortunatley, have the same name as modules from the other project) have the correct dependencies, and yeoman build results in a functioning app.

Specifically, I have modules models/session in two different apps, in two different locations on my disk. They perform very different functions – one requires collections/asset, and one requires nothing. When I'm in the project to which the latter belongs, and I run yeoman server, RequireJS throws a 404 for the missing collections/asset, even though that isn't mentioned in the models/session used in this app.

What's going on? Is there a cache I can reset? How can I keep my modules from sullying each others' namespaces in the eyes of yeoman?

thure commented Nov 19, 2012

I should add that in the other project I'm getting the same issue: tons of 404s for modules that aren't listed as dependencies. This makes yeoman server basically unusable in this situation, where multiple projects use RequireJS and yeoman together. Again, yeoman build works just fine and yields a working app.

If anyone is having the same issue, I've been able to just call yeoman build in the interim with this special task alias added to the Gruntfile:

grunt.registerTask('build','intro clean compass mkdirs copy time');

This only works if Chrome is opened with web security disabled.

Contributor

sleeper commented Nov 20, 2012

You mean that your build target is only working if you open Chrome with web security disabled ?

I'm going to have a look at this issue tonight or tomorrow morning.

thure commented Nov 20, 2012

The build target isn't the issue – it is a temporary "solution". I shouldn't use build that way, but I do because server is unusable given the situation described in the original question.

Contributor

sleeper commented Nov 20, 2012

Agreed, but still the issue your encounters on build is strange from my POV ;)

thure commented Nov 20, 2012

Oh, Chrome's web security thing only comes up because I'm opening it using the file:// protocol rather than having a server serve it. Chrome cancels asynchronous requests between apps served over file:// on web security grounds.

Contributor

sleeper commented Nov 20, 2012

OK. I'm able to reproduce it ... which is easier to debug ;)

Contributor

sleeper commented Nov 21, 2012

I guess I understood the root cause of the issue: it seems to be due to the browser cache.
1st time your browser requests for the model/session (the one depending on collections/asset) and gets it from the server.
2nd application is ran: the browser request for model/session (which is for same origin/same port -- localhost/3501) ... browser gets it from its cache ... but the cached version is the one with the dependencies on collection/asset)

thure commented Nov 26, 2012

Oh, I see now. Can the rev task be applied here?
For now I'll just test iterations using an incognito window.

Contributor

sleeper commented Nov 26, 2012

Actually, I've been able to reproduce the issue even in incognito mode !
I guess the safest would be to use the pragma no-cache for development purpose ... Didn't had time to have a look at it though :(

thure commented Nov 26, 2012

Oh, how bizarre; so far incognito mode has worked for me… maybe it'll break soon? Hm…

Contributor

sleeper commented Nov 26, 2012

From my point of view it should work ... so I guess its more a by-product of the Chrome dev version ;)

vail130 commented Dec 7, 2012

I've been having the same issue lately. Incognito has helped sometimes. META tags in the HTML have not helped. I tried inserting the following

<META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE">
<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">
<META HTTP-EQUIV="Expires" CONTENT="-1">

into the HEAD tag, and even added another HEAD tag with those META tags at the end of the document, as described in http://support.microsoft.com/kb/222064. None of this had an effect.

Any other suggestions? I'd love not to resort to another browser...

EDIT:

Nevermind! Something else was wrong, and it wasn't yeoman:

I was using the fileupload plugin for jQuery (https://github.com/blueimp/jQuery-File-Upload), and I didn't realize that it had a dependency for jquery.ui.widget in its code for when it's loaded through AMD.

Lesson: Check the AMD dependencies of your plugins!

Owner

addyosmani commented Dec 17, 2012

I guess the safest would be to use the pragma no-cache for development purpose

If we can find time to experiment with this that would rock. Also, sorry about Chrome dev :)

This is a little bit of a crazy solution... Set up a DNS record for some domain (lets say server.yeoman.io) that redirects *.server.yeoman.io to 127.0.0.1 (localhost). Then when you start the server you open the users browser to http://<project name>.server.yeoman.io:8000/. Now each project resolves to a different origin, stopping the browser from giving you incorrect cache items.

Probably a stupid idea, but thought I would throw it out there. The main issue that springs to mind is what to use for "project name"

Owner

sindresorhus commented Jan 31, 2013

We're now using a default Connect server and another requirejs grunt task. If this is still an issue after the 1.0 release please reopen.

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